Neutrino-Images

Hi
Es gab/gibt halt Probleme mit den Umbauten an den frontends.
Deswegen hat sich das Team entschieden, erstmal zu reverten.
vanhofen hat das aber absichtlich in einem commit zusammengefasst.
Da du ja auch selber baust, brauchst ja auch nur den einen commit bei dir zu reverten.

gr. Knicko

Da es sonst nicht erwähnt wurde, habe ich es mal gepostet.
Nicht jeder schaut regelmäßig in die Liste der Commits, schon garnicht in die damit verbundenen Diffs.

Und zu meiner "Differenz" im Scanergebnis bin ich auch fündig geworden:
Tausch der Leitungen => keine Änderung mit Port 3 und 4!
Es war im Ausschlussverfahren dann ein SUR 210 F - Optionsschalter (DiSEqC 1.0) der anscheinend sein Mindesthaltbarkeitsdatum überschritten hat.
Schalter ausgewechselt => beide Boxen jetzt wieder mit gleichem Ergebnis.

Kann ich mir endlich einen weiteren 2.1-er Schalter bei der Regierung beantragen, kaufen und die frontend.conf wieder einheitlich halten.

Bei der ersten Kanalsuche auf dem Kabeltuner ist die Broadcaster-ID ( cable_nid= in /var/tucbox/config/scan.conf ?) nicht korrekt vorbelegt.
Sollte ja bei einem jungfräulichen Image entweder "0" oder "1" sein.

Sieht aber aus, als wäre die Variable vor Öffnen des Dialogfensters nicht korrekt deklariert/initialisiert.
Da erscheint was mit insgesamt 9 Stellen.

Workaround:
Kann man im ersten Schritt 5 Nullen drüberschreiben, im zweiten Schritt dann noch 4 Ziffern mit 0001 übeschreiben, um den ersten Kabel-Anbieter in cables.xml auszuwählen.

Janus hat geschrieben: ↑Mo 7. Dez 2020, 19:25... tucbox ...

scnr

Wegen der Vorbelegung schaue ich dann mal nach.

Die Vorbelegung (s.o.) passt noch nicht! (Build: Stand von Gestern)

Dafür scheint nach den letzten Commits der Betrieb mit den aktuellen Treibern wieder möglich.

+ Scans der 'normalen' Satpositionen (13, 16, 19.2) - Kabel sowieso - sind soweit ersichtlich volltändig.

Die Problemzonen (S2X, MiS) teste ich spätestens zum Wochenende, wenn die Box wieder komplett konfiguriert ist...

Janus hat geschrieben: ↑Mi 3. Feb 2021, 12:44 Die Vorbelegung (s.o.) passt noch nicht! (Build: Stand von Gestern)

Ist gefixt. https://github.com/neutrino-images/ni-n ... 2ffd5e0758
Da gab es einen Logikfehler mit upgradeSetup(), wenn keine Config existiert.

MMmhhhmmmm...
Ja, ja, ich finde immer die Hartnäckigen.

Wenn du das immer noch so hast, war Wert, den du angezeigt bekommst, in scan.conf falsch abgespeichert. Ebendieses falsche Speichern habe ich repariert.
Lösche den Wert in scan.conf.

Zum Testen: Benenne scan.conf und neutrino.conf um und durchlaufe den Startassi. Da bekommst du diese Phantasiewerte nicht mehr gezeigt und auch nicht gespeichert.

Ich fürchte, der "Fehler" ist mein - vielleicht unübliches - Vorgehen bei Tests und Neuinstallationen der Firmware bei Multituner-Boxen, insbesondere wenn mehrere Delivery-Systeme verfügbar sind.

Ich habe daher mal scan.conf als Historie meines Vorgehens abgelegt.

scan.000:
=> Stand nach automatschen Erst-"Initialisierung" von neutrino.conf und wohl auch scan.conf durch Neutrino (ohne Frontend-Kofiguration und Suchläufe).
Alle Werte sind in scan.000 eigentlich sinnvoll vorbelegt.

Nach der vollständigen Einrichtung der Benutzeroberfläche und "Einspielen" meiner eigenen XML-Scanvorlagen (satellites, cables, terrestrial, providermap) muss ich ja die Box neu starten, damit die Scanvorlagen wirksam werden.

scan.001:
=> Stand nach dem o.g.Neustart (immer noch ohne Frontend-Kofiguration und Suchläufe).
Fast alle Werte sind jetzt mit seltsamen Werten belegt. Die kommen mir vor wie Daten aus einer nicht instanzierten/initialisierten Speicherstruktur.
Also: scan.conf war eine nette Textdatei aber der eigentliche Speicherbereich im RAM (?) ist nicht mit diesen Werten belegt.
Beim Speichern werden dann diese nicht initialisierten Werte weggeschrieben.


Danach beginne ich mit der Frontend-Konfiguration, idR (nur) mit Astra 1 auf Tuner A und DiSEqC 1.1 (com=1 uncom=1).

scan.002:
=> Nach dem erfolgreichen Scan ist scan.conf noch nicht aktuaslisiert, obwohl im RAM wohl schon die richtigen Werte stehen dürften.

scan.003:
=> Nach Neustart sind die Werte soweit dann auch in der scan.conf.
Die Werte aller anderen Delivery-Systeme oder Sonderregelungen sind aber immer noch mit den seltsamen Werten belegt.
Waren ja anfangs so gespeichert, werden also auch so wieder eingelesen.

scan.004:
=> Auf Tuner B Hotbird mit DiSEqC 1.0 (Port 2) eingerichtet, erfolgreich gescannt
scan.005:
=> und anschließend noch einen erfolglosen manuellen Einzeltransponderscan durchgeführt.

scan.006:
=> Kabelscan eingerichtet (271985700 durch 1 ersetzt) und gescannt
cable_nid=1 sieht gut aus!

scan.007:
=> Manueller Einzetransponderscan mit Kabeltuner erfolgreich durchgeführt.
Alle kabelbezogenen Werte sind nun eingetragen.
Fazit:
Ich denke, das eigentliche Problem liegt bei der ersten Speicherung der scan.conf.
Solange vorher keine komplette Frontend-Konfiguration und Scan (aller Delivery-Systeme) durchgeführt wurde, sind die wegzuschreibenden Werte nicht alle initialisert. Beim Wiedereinlesen der scan.conf nach Neustarts werden dann diese Werte darin eingearbeitet.
Fällt bei Singletuner-Anlagen eher nicht auf, weil dort meist beim Erststart auch ein Scan der Services ausgeführt wird.


Ansonsten:
Alle Jahre wieder schlage ich eine strukturelle Überarbeitung der Konfigurationsdaten/-dateien vor.
Bei konsequenter SeparationOfConcern dürften solche Sachen viel seltener Auftreten als jetzt, wo die Sachen verstreut, teilweise doppelt oder inzwischen längst obsolet sind. Und je mehr Goodies neuere Hardware bietet, umso größer die Brownfield-Gefahren.

Es gibt z.B. Neutrino-Builds, da findet sich immer noch eine sat.conf, die - soweit es aussieht - parallel zur frontend.conf auch noch aktuell gehalten wird.
War die fast/fst - Abteilung in scan.conf nicht für die inzwischen nicht mehr vorhandene ProviderScan-Option (fastscan) in der CST-Firmware ?

Janus hat geschrieben: ↑Di 9. Feb 2021, 15:46 Ich denke, das eigentliche Problem liegt bei der ersten Speicherung der scan.conf.

Korrekt. Und genau das habe ich gefixt.

scan 001-005 sind in deinem Archiv noch falsch.

scan 001-005 sind in deinem Archiv noch falsch.

Das ist Source-Stand von Gestern und Test von Heute ?!?

OK. Keine Ahnung, wie du das hinbekommst.

Einen Safety-Fix habe ich noch. Das ist dann zwar doppelt gemoppeltes Doppelgemoppel, aber einen Versuch ist es Wert.
https://github.com/neutrino-images/ni-n ... 25dc95beec

Keine Ahnung, wie du das hinbekommst.

Ich versuche es nochmal:
Umittelbar nach dem Build der aktuellen GIT-Version - mit Deinem Commit - hat "make image" die folgende Datei:

bouquetMode=3
cableName=F01 UnityMedia
cable_TP_delsys=4
cable_TP_fec=0
cable_TP_freq=266000
cable_TP_mod=5
cable_TP_rate=6900000
cable_nid=271985700
fast_op=274947105
fast_type=275934240
fst_update=272972835
fst_version=273959970
satName=686 Hotbird
sat_TP_delsys=2
sat_TP_fec=3
sat_TP_freq=11566000
sat_TP_mod=9
sat_TP_pilot=-1871250631
sat_TP_plc=1
sat_TP_pli=0
sat_TP_plm=0
sat_TP_pol=0
sat_TP_rate=29900000
scanType=96
scan_bat=280869915
scan_fta_flag=279882780
scan_logical_hd=276921375
scan_logical_numbers=277908510
scan_nit=-1868508391
scan_nit_manual=-1869495526
scan_reset_numbers=278895645
terrestrialName=
terrestrial_TP_bw=-1869603481
terrestrial_TP_coderate_HP=-1869092761
terrestrial_TP_coderate_LP=-1871512216
terrestrial_TP_constel=-1867184026
terrestrial_TP_delsys=275891820
terrestrial_TP_freq=
terrestrial_TP_guard=-1871067031
terrestrial_TP_hierarchy=-1873486486
terrestrial_TP_pli=
terrestrial_TP_transmit_mode=-1873041301

erzeugt. (root/var/tuxbox/config/scan.conf)
Die natürlich auch im rootfs fürs Image so übernommen wird.
Damit wäre eigentlich klar, woher die seltsamen Werte kommen. (Nicht von mir)

Wenn ich die Dezimalzahlen mal in den Hex-Rechner eingebe, kommen da - zumindestens bei den negativen Zahlen - 64bit Werte raus.
Könnte es sein, dass es doch Inkompatibilitäten zwischen 32bit-Code und 64bit-Prozessor gibt ?

Janus hat geschrieben: ↑Mi 10. Feb 2021, 13:09 Umittelbar nach dem Build der aktuellen GIT-Version - mit Deinem Commit - hat "make image" die folgende Datei:

bouquetMode=3
cableName=F01 UnityMedia
cable_TP_delsys=4
cable_TP_fec=0
cable_TP_freq=266000
cable_TP_mod=5
cable_TP_rate=6900000
cable_nid=271985700
...
erzeugt. (root/var/tuxbox/config/scan.conf)

Unser Image wird definitiv ohne scan.conf ausgeliefert. Wenn die Datei in deinen Eigenbau-Images enthalten ist, dann liegt der Fehler an deinen Vorlagen.

Nachdem ich scan.conf gelöscht und dann neu konfiguriert und gescannt habe, sieht das Alles gut aus.

Die Herkunft der verhuddelten scan.conf ist mir nicht ganz klar.
Zuerst war das im Nightly aus dem Download, dann in meinem master-Selbstbau nach all-clean und rebuild.clean.
Mit dem aktuellen Selbstbau von Heute bin ich mir nicht ganz sicher, weil ich davor nur ein neutrino-clean gemacht habe.
Die vorherige Version von Gestern war aber auch ohne Personalisierung.

Aber egal, jetzt scheint es ja irgendwie doch in Ordnung zu sein...

Beim Konfiguration-Versuch von minisatip auf der Duo4K (1xS2X-FBC, 1xC-FBC) ist mir aufgefallen, dass sich in der Tunerkonfiguraation die Tuner ab 11 (== 10 in der zugrundeliegenden nullbasierten Aufzählung) nicht mehr aufrufen lassen.
Es erscheint dann bei den weiteren immer nur der Tuner 02.
Da stimmt vielleicht das Mengenrüst (nur 0..9 ?) nicht.

Ist mir bisher nicht aufgefallen, da die Kabel-Subtuner automatisch korrekt auf "independent" eingestellt waren.
Für die (exklusive) Nutzung von minisatip wollte ich zu dieser "Reservierung" die beiden letzten Subtuner des DVB-C FBC für Neutrino "abschalten".
Habe jetzt erstmal manuell fe14_Mode und fe15_mode auf Null (nicht benutzt) gestellt.

Sieht jetzt so aus:

Janus hat geschrieben: ↑Di 13. Apr 2021, 14:14Beim Konfiguration-Versuch von minisatip auf der Duo4K (1xS2X-FBC, 1xC-FBC) ist mir aufgefallen, dass sich in der Tunerkonfiguraation die Tuner ab 11 (== 10 in der zugrundeliegenden nullbasierten Aufzählung) nicht mehr aufrufen lassen.
Es erscheint dann bei den weiteren immer nur der Tuner 02.

Wie genau meinst Du das? Bekommst Du nicht alle FBC Tuner angezeigt wenn Du unter Neutrino alle Tuner abschaltest?

Betrifft nur NI.
Ich kann ab dem 11. Tuner - also dem dritten DVB-C Tuner - nicht mehr per UI (Menü > Service > Tuner Einstellungen) auf die Tunerkonfiguration zugreifen.
Im Dialog wird mir danach immer nur Tuner 02 zum Ändern angeboten.

Im BPanther geht das korrekt.
<falsches Forum>
Dafür geht da die DiSEqC 1.1 -Einstellung wieder nicht mehr wie sie sein sollte.
(Obwohl ich das vor einiger Zeit schon mal gefixt hatte. Im NI geht es ja)
Wenn ich mir mit der Fehlerbeschreibung sicher bin, mache ich wegen der Zuständigkeit dort eine Fehlermeldung.
(Und vielleicht ein kleines DiSEqC-HowTo )
</falsches Forum>

@Janus: Alles klarbezüglich Tunereinstellungen.

Zum Diseqc bei mir: Das mußte wieder zurückgesetzt werden, da was anderes damit nicht mehr funktionierte. Aber keine Ahnung, was das nun wieder war...

* mit gestecktem Modul wird bei einem Neustart der festgelegte Startsender nicht getuned.
Solange das Modul steckt funktioniert auch kein anderer Sender, egal welcher Tuner (S, C) angesprochen ist.
Modul ziehen:
+ Sender Umschalten => geht
+ Modul wieder einstecken => nach Pause/Standbild (wegen der Initialisierung) 'wacht' zuvor eingestellter Sender wieder auf.
Je "plussiger" das Modul, um so länger dauert das. Logo!

* Ich vermisse in meiner Duo4K die Einstellungen der CI-Zuordnungen zu Tuner und/oder Bouquet-Typ.
Lediglich die "Erlaubnis" im Kontextmenü ist noch da.
Bei meinem Tank ist wenigstens noch die Tunerzuordnung in der "Zugangskontrolle". Auf HD51 und Duo4K fehlt das.
Die früher vorhandene Auswahl bzgl. Bouquets (nur Favoriten, nur markierte Bouquets...) ist aber auch auf dem Tank nicht mehr vorhanden.
Einziges Selektionskriterium ist dann aktuell nur noch die Zuweisung an das CI im Kontextmenü der Bouquet-Verwaltung.

* In neutrino.conf der Duo4K stehen zwar Konfigurations-Einträge für ci.0 und ci.1, aber irgendwie habe ich das Gefühl, dass das CI-Handling intern nicht immer hinhaut. (siehe auch oben)
Ich habe jedenfalls häufig Probleme, wenn ich ein "einzelnes" Modul in den Slots wechsle (bei gleicher Konfguration und ggfls. vorhandenen Authentifizierungen für beide Slots) oder zwei Module verwende.
[Module (CI und CIplus+Karte) funktionieren in der HD51 und dem Tank einwandfrei]
Falls das Verhalten bekannt ist, wo im Source müsste ich überall suchen ? (libcoolstreams sind da ja wohl obsolet)
Wenn nicht, würde ich mal ein paar Logs machen.