Duo4K - Fehler & Vorschläge

[Janus]

Ich könnte einen Grund für die partielle Fehlfunktion bei der Entschlüsselung der Kabelsender gefunden haben:

Sat-Sender über Tuner A (Tuner 1 == fe0 !!):
==> [capmt.cpp:SetMode:250] PLAY: fe_num 0 dmx_src 0

Kabel-Sender über Tuner "I" (Tuner 8 == fe7 !!) --> ( Tuner 9 == fe8 )
[capmt.cpp:SetMode:250] PLAY: fe_num 8 dmx_src 8

Das sieht nach einem Flüchtigkeitsfehler ... des Threaderstellers ... aus!
Sorry !

[Janus]

Ich habe aber trotzdem noch Einen:

In den Tunereinstellungen für Sat fehlt in der Zeile "Auswahl Satellit" rechts die Angabe zu aktiven und gesamten Satpositionen => 16/24 (oder so ähnlich)


Und einen Vorschlag dazu:
Irgendwo habe ich mal Optionen zur einfachen Übenahme bestehender Tunerkonfiguration(en) gesehen. Zum Beispiel "wie Tuner #" oder "für alle Tuner".

[BPanther]

Ich verstehe nicht mit dem Sat was Du da meinst und wozu das mit dem XX/YY gut sein soll.

Eine Übernahme der Einstellungen erfolgt automatisch, wenn man nicht "Independet" benutzt. Ich weiß jetzt nicht, wo/wann genau das fehlt.

[Janus]

Ich habe ein Beispiel von der HD51 genommen. (die Duo4K ist momentan offline)

screenshot_osd_tunerconfig.png

Meine satellites.xml enthält derzeit 31 Satpositionen und in der HD51 sind alle 31 konfiguriert.

Ergibt

Auswahl Satellit --> (da alle konfiguriert sind) --> 31/31

Auf der Duo4K sind derzeit für Test
auf Tuner A => 5 von 31 (28.2E, 23.5E, 19.2E, 13E, 9E und 5W) - also müsste da stehen 5/31
und auf Tuner B => 3 von 31 (19.2E, 19.1E und 13E) - und hier 3/31
zugewiesen.
Aber leider steht das im Tuner-Einstellungsdialog des BP-Images nicht! (aktuell 18374 multi)

Ich habe die übrigen Sat-Tuner per Editor in frontend.conf manuell kopiert - 2..4 wie Tuner A und 5..7 wie Tuner B - und per PowerOFF/ON "integriert".

Wenn ich das für 31 Satpositionen in 8 Frontends über das UI pflegen müsste, würde ich mir eine vereinfachte Übernahme im Einstellungdialog wünschen.

Tuner Modus == Independent
Einstellung === wie Tuner A

Nicht jeder Anwender ändert mal so eben die frontend.conf per Hand ...
... und bekommt das auch hin!


Axo:
Ich glaube nicht dass Neutrino in der Lage ist, wie Enigma die Tuner C bis H im laufenden Betrieb automatisch nach Bedarf - und Angebot - korrekt zu vergeben.
Habe ich allerdings bisher weder mit Neutrino noch mit Enigma probiert.

[BPanther]

Auswahl Satellit --> (da alle konfiguriert sind) --> 31/31

Also das halte ich für überflüssig und unwichtig, ich sehe da auch nicht wirklich einen Sinn darin. Zudem hat das DDT auch nicht eingebaut - wird von mir auch nicht kommen.

Ich habe die übrigen Sat-Tuner per Editor in frontend.conf manuell kopiert - 2..4 wie Tuner A und 5..7 wie Tuner B - und per PowerOFF/ON "integriert".

Eine Unsitte mit Power on/off - genau wie bei einigen Images und Scripten mit dem reboot -f. Wer seine Dateisysteme zerlegen will, soll mal ruhig weiter so machen - sich aber dann nicht wundern.
Man kann die fertige Datei auch im FTP halten und per normalen Neutrino Neustart via Extras dann während dem Neustart überschreiben. Gerade mit emu hat man in der Regel genug Zeit dafür.

Wenn ich das für 31 Satpositionen in 8 Frontends über das UI pflegen müsste, würde ich mir eine vereinfachte Übernahme im Einstellungdialog wünschen.

Auf der einen Art verständlich, anderseits macht man aber meist nur einmalig und dann nie wieder. Ist auch eine Datei, die normalerweise ins Backup übernommen wird.

Ich glaube nicht dass Neutrino in der Lage ist, wie Enigma die Tuner C bis H im laufenden Betrieb automatisch nach Bedarf - und Angebot - korrekt zu vergeben.
Habe ich allerdings bisher weder mit Neutrino noch mit Enigma probiert.

Das mußt Du mal bitte genauer erklären. Wenn ich z.B. eine Aufnahme mache und dann umschalte, hat die Aufnahme A, das neue Live Programm Tuner B - wenn man denn will entsprechend der Einstellungen im Tunermenü. Startet man eine weitere Aufnahme wird das Tuner B oder C, je nachdem was gerade Live ist und wo die zweite Aufnahme läuft usw. Das klappt hier. Ansonsten wie gesagt bitte genauer erklären was gemeint ist.

[Janus]

bitte genauer erklären was gemeint ist

Ich nutze die beiden Zuleitungen, um unterschiedliche Broadcaster-Konfigurationen "anzuliefern".

Leitung 1 (Tuner A) hat Zugriff auf Astra1/Hotbird-Multischalter und steuert über Optionsschalter die Motorschüssel.

Leitung 2 (Tuner B) hat nur Zugriff auf Astra1/Hotbird-Multischalter und meinen Dummy-Satelliten Astra 1+ (pos 191, auch DiSEqC=1), der zur eindeutigen Trennung von CI+ Services vom Rest dient. Alle dem CI+ zugewiesenen Bouquets sind nur über diese SatPosition erzeugt.
Die Leitung 2 liefert auch das über den Multischalter eingespeiste Kabelsignal, was in der Anschluss-Dose wieder zuverlässig abgetrennt wird. (da dort kein Optionsschalter diese Leitung unterbrechen kann!)

Diese Konfiguration hat verhindert, dass ein Streaming-Zugriff auf das CI+ (von einer anderen Box) den Tuner A umschaltete. Das hat sich auf dem Tank seit Jahren bewährt.
Ich habe daher Tuner 3 - 5 (C - E) wie Tuner A konfiguriert und Tuner 6 - 8 (F - H) wie Tuner B.

Neutrino muss also wissen, dass meine Sky-Sender nur über die Tuner B, F - H erreichbar sein dürfen, obwohl parallel auf allen Tuner das normale Astra 1 ebenfalls zur Verfügung steht.

Ich kann das leider nicht testen, da mein Sky+Cam in der Duo4K (von mir) bisher nicht in Betrieb genommen werden kann. Das Sky+Cam wird inkusive Athentifizierung initialisiert. Sobald das Teil aber gesteckt ist, werden garkeine Sender mehr getuned. Das kann natürlich auch eine falsche Bestückung von /etc/ssl/certs sein. (ich habe die pem-Dateien aus der OpenATV-Installation kopiert)

[BPanther]

Das Tuning selbst muß aber funktionieren - also kein "Kanal nicht verfügbar" - egal ob mit oder ohne Modul. Ich hatte auch eine zeitlang von einem Bekannten ein Sky Modul da und damit keine Probleme was das Tuning betrifft, einzig mit der Decodierung hatte es Probleme (zerlegte Bilder), aber auch OATV hatte das. Mit der richtigen Konfig lief es dort aber. Deswegen hatte ich auch in Neutrino die CI Modul Optionen angepasst und erweitert, so daß die Optionen für jeden Slot einzeln einstellbar sind, da das Sky Modul etwas andere Einstellungen benötigt.

Neutrino muss also wissen, dass meine Sky-Sender nur über die Tuner B, F - H erreichbar sein dürfen, obwohl parallel auf allen Tuner das normale Astra 1 ebenfalls zur Verfügung steht.

Nur wie soll das unterschieden werden? Bei Deiner Tunerkonfig kennen ja beide Tuner den gleichen Sat (19.2E) und somit wird auch immer der erste freie Tuner mit diesem Sat benutzt. Würde Tuner A nicht 19.2E kennen würde ein anderer Tuner genommen werden, der auch 19.2E kennt.

[Janus]

Jetzt fast eine Stunde an der Antwort mit präziserer Fehlerbeschreibung gearbeitet.
Und kurz vorm Absenden irgendwie blöd an eine Taste gekommen => Alles weg.

Sorry
Mach' ich halt Morgen nochmal. Jetzt keinen Nerv mehr...

p.s.
Wie sieht es mit den Boardregeln aus ?
Das Thema an sich ist ja nicht völlig unproblematisch...

[BPanther]

Mach das in Ruhe, rennt alles nicht weg.

Wie sieht es mit den Boardregeln aus ?
Das Thema an sich ist ja nicht völlig unproblematisch...

Solange hier keine Keys, Dateien oder direkte Anleitungen auftauchen ist das OK. Hier gehts ja im Prinzip darum wie man einem CI Modul klarmachen soll, einen bestimmten Tuner zu nutzen (oder andersrum), betrifft dann ja auch andere Module wie z.B. Conax und MTV.

[thomas]

Dummy-Satelliten Astra 1+ >>> ist absolut unnötig und unsinnig

[Janus]

kennen ja beide Tuner den gleichen Sat (19.2E)

Das stimmt! Diese Sender sollen ja auch über z.B. über eine weiße HD+ - Karte (0x1830 ohne CI) behandelt werden.

Die Magie liegt
+ in der nur teilweisen Verfügbarkeit von Astra 1+ (19.1E),
+ gezielte Beschränkung dieser "Position" auf Sender dieses CI+Providers,
+ den paketorientiert angelegten User-Bouquets gemäß Abo-Umfang
und - ganz wichtig -
+ der festen Zuordnung nur dieser "Spezial-Bouquets" zur CI-Nutzung über das Kontextmenü.
(Und das ganz ohne illegale Umgehungeinrichtung zur Steuerung)

Dieses eigentlich unnötige und unsinnige Prinzip ermöglicht es zum Beispiel auch, neben einem Sky+Cam auch ein HD+Cam parallel zu betreiben, ohne dass sich die 0x098C Anfragen ins Gehege kommen. Oder andere Sachen ohne Aufwand parallel zu betreiben.

Also muss Neutrino wissen, welche Satpositionen auf welchem der Tuner zu finden sind.
Und das auch zverlässig nutzen. Macht es ja auch, z.B. im Tank.
Auch meine Motor-Positionen sind nur über eine Leitung zu erreichen. Die zweite Zuleitung (direkt zum Multischalter, im Tank zu Tuner 2, in der Duo4K zu Tuner B) kann mit Optionsschaltern oder USALS-Befehlen absolut nix anfangen !
Also auch das muss selektiert werden.

Der Frontend-Manager muss das nun auch für FBC-Tuner lösen. Und das CA-Handling (CI, CI+, Kartenleser etc.) muss dem folgen.

Mein Problem mit dem Sky+Cam - "Kanal (zur Zeit) nicht verfügbar" - werde ich wohl besser in einem eigenen Post schildern. Dieser Text ist ja eh schon lang genug.
Vielleicht gibt es das Problem auch garnicht mehr, wenn das Sky+Cam (s.o.) dem Frontend "folgt".


Ich bitte, das nicht als Gemecker zu verstehen.
Ich wusste beim Kauf der Duo4K ziemlich genau, auf was ich mich da einstellen muss.
Ist auch nicht das erste Mal, dass ich mich an der Portierung und Weiterentwicklung von Neutrino auf zeitgemäße Hardware beteilige.
Ich möchte halt nur weiterhin in einer enigmafreien Zone leben...

[BPanther]

Dieses eigentlich unnötige und unsinnige Prinzip ermöglicht es zum Beispiel auch, neben einem Sky+Cam auch ein HD+Cam parallel zu betreiben, ohne dass sich die 0x098C Anfragen ins Gehege kommen. Oder andere Sachen ohne Aufwand parallel zu betreiben.

Nun, das kann man aber auch einfacher haben, denn genau dafür gibts doch die blacklist pro CI Modul Schacht. Warum nutzt Du die nicht? Da werden die gesperrten Sids einfach eingetragen und somit nicht mehr an das Modul übertragen.

Der Frontend-Manager muss das nun auch für FBC-Tuner lösen. Und das CA-Handling (CI, CI+, Kartenleser etc.) muss dem folgen.

Nunja, der ganze FE-Manager incl. Demuxer etc. müsste eh mal komplett überarbeitet werden, denn sonst würde es ja auch nicht die Probleme geben mit den neueren Kernelmodulen. Und das liegt eindeutig an Neutrino selbst, nicht am Kernel oder was auch immer, denn ich habe schon mal Neutrino incl. benötigte Libs einfach in ein E2, was keine Probleme hat, kopiert und die Probleme waren die gleichen wie mit reinem Neutrino. Nur wer traut sich daran? Das mit dem CI-Problem betrifft zwar nur die beiden Uno's, aber auch bei den anderen Boxen hätten die aktuellen Module durchaus Vorteile, z.B. "mehrere Aufnahmen zeitgleich".

Mein Problem mit dem Sky+Cam - "Kanal (zur Zeit) nicht verfügbar" - werde ich wohl besser in einem eigenen Post schildern. Dieser Text ist ja eh schon lang genug.
Vielleicht gibt es das Problem auch garnicht mehr, wenn das Sky+Cam (s.o.) dem Frontend "folgt".

Denke eher die Lösung ist obig erwähnte Blacklist.

Ich bitte, das nicht als Gemecker zu verstehen.
Ich wusste beim Kauf der Duo4K ziemlich genau, auf was ich mich da einstellen muss.
Ist auch nicht das erste Mal, dass ich mich an der Portierung und Weiterentwicklung von Neutrino auf zeitgemäße Hardware beteilige.
Ich möchte halt nur weiterhin in einer enigmafreien Zone leben...

Keine Sorge, verstehe ich nicht als Gemecker - und ich hoffe Du auch nicht von meiner Seite aus.

[Janus]

dafür gibts doch die blacklist pro CI Modul Schacht

Keine Ahnung, dass es die gibt. Habe ich bisher immer nur im Zusammenhang mit oscam von gelesen.
Wo finde ich die denn überhaupt?

Warum nutzt Du die nicht?

Brauch' ich ja nicht...
Kenne mich mit dem Settingshandling von Neutrino und der Settingsverwaltung ganz gut aus!

der ganze FE-Manager incl. Demuxer etc. müsste eh mal komplett überarbeitet werden

Das habe ich schon bei der Einführung von Multituner und Streaming-Optionen angeregt.
Wäre damals - wie immer - wahrscheinlich einfacher gewesen.

Der einzige Erfolg war in der Anfangszeit von NeutrinoHD die Umstellung von sat.conf auf frontend.conf.
Die Zerstreung von frontend-relevanten Daten wurde dabei eher gefördert als beseitigt.
(scan.conf, zapit.conf, neutrino.conf)

Keine Ahnung, ob diese Vorschläge noch in erreichbaren Foren zu finden sind.
Prinzipiell sollte das auch in strukturunterstützendem XML realisiert werden.
=> ESDB (Equipment Structure DataBase)
als Container für die Konfigurationsdaten von Frontends, Boxen und Backends.

Steinalt:

esdb.xml.txt

[BPanther]

Von dem XML Kram halte ich persönlich garnichts. Wir sind nicht im Netz und wollen eine Seite darstellen sondern haben normale Programme die Ihre Konfig abspeichern sollen. Zudem viel zu umständlich von Hand zu bearbeiten, unübersichtlich und gerade für Laien kaum zu durchschauen wo man was findet. Da sind mir klare Textdateien, von mir aus auch im Format der os.conf weitaus lieber. Da brauchts keine extra Programme sondern nur einen einfachen Editor.

scan.conf, zapit.conf, neutrino.conf - haben alle so gesehen durchaus ihre Berechtigung. Die eine ist halt für die Scanparameter, die andere für die Zapit Einstellungen und die letzte für die normalen Neutrino Einstellungen. Das alles z.B. nur in die neutrino.conf zu legen halte ich persönlich nicht für sinnvoll. Klar, man möchte meinen, daß im Grunde eh alles von Neutrino verarbeitet wird, ist es aber streng genommen nicht wirklich. Nichts ist direkt übergreifend, alles wird über "Krücken" sozusagen verbunden. Das haben andere zum Teil etwas besser gelöst. Da war das früher eindeutiger mit den Programmen, z.B. war der nhttpd ein echtes eigenständiges Programm, was durchaus auch Vorteile hatte. Man könnte jetzt sagen: "Historisch so gewachsen und als gegeben hinzunehmen.", aber es wird letztlich nicht besser. Wenn sich am Frontend/Demux etc. nichts ändert, wird es wohl bei anderen (neueren) Boxen noch mehr Probleme geben. Und ich meine damit erstmal vorrangig den Demux Kram, denn da ist definitiv was im argen. Meine Experimente dazu waren bisher nicht erfolgreich, obwohl ich seit einigen Image-Versionen schon eine geänderte pat.cpp benutze ohne while schleife beim einlesen von service_id und pmt_pid. Auch stimmt der Demux Teil in der HAL ganz und garnicht für die VU+ - steht sogar ("schon immer") als Kommentar so da (HIER). Komplett falsch von mir eingebaut, mußte ich aber dennoch so machen sonst würde garnichts richtig bei denen gehen. Erstaunlich, daß das noch keinem aufgefallen ist, denn alle haben den Commit von mir übernommen - oder es hatte schlicht keiner eine Idee wie man das richtig umsetzen müsste.

Letztlich bringt aber alles nichts, denn solange sich da keiner findet der das kann und auch Lust hat das in Angriff zu nehmen, wird sich an diesen Problemen nichts ändern - und es werden auch die beiden Unos, bei SAT zumindest, ohne CI auskommen müssen.

Achja... Die Datei blacklist_slot_X kommt nach /etc, muß man selbst anlegen. Dort kommen die unerwünschten SIDs hinein (keine CAIDs), normale Textdatei. Mehrere SIDs einfach durch Komma trennen.

[blacky49]

Die /etc/blacklist_slot_[n] wird vom Cam Handler in libhal ausgewertet, nicht von Neutrino oder oscam !

Z.Bsp. eine : /etc/blacklist_slot_0 bewirkt, das bei den darin enthaltenen Service SID´s das CI-Modul in Slot 0 nicht aktiviert wird,
bzw. wenn es vorher aktiv war sozusagen inaktiv wird.

Hier ein Beispiel Inhalt dieser blacklist:

Code: Alles auswählen

132F,1330,1331,4E27,0046,3332,3262,32C9,32CA,32CB,32CC,32CD,32CE,32CF,32D0,32D1,32D2,32D3,32D4,3337,33A7,33A5,31FC,332D,33AC,33FC,1485,33fd

So gibt es eine friedliche Koexistenz zwischen Ci-Modul und oscam...