raceroad

Vorweg: Mir ist kaum klar, wie Image, E2-Basis und Treiber zusammenspielen. Dennoch melde ich mich hier. Mein unter OpenPLi (4.0) laufender Receiver (ET 9200) sollte eben zuverlässig funktionieren.

Dass etwas nicht einwandfrei funktioniert, ist mir zunächst beim Fenstertausch mit Beteiligung (mind.) eines HD-Programms aufgefallen. Für PiP wäre ein Fehler noch halbwegs zu verkraften, aber nicht nur PiP ist betroffen (s.u.). Nachvollziehen lassen sich die Vorgänge aber am besten beim Fenstertausch. Dazu zwei Beispiele unter der Rahmenbedingung, dass mittels PiP-ServiceRelation für das kleine PiP-Bild SD genutzt wird und daher zum Fenstertausch (mind.) ein Tuner einen neuen Transponder vom Unicable-Router anfordern muss:

• Ausgangssituation 1: Hauptbild ZDF HD (SR 22000) / PiP-Bild WDR (Köln) SD (SR 27500)
• Rektion auf Fenstertausch:
• PiP-Bild  (Zuordnung der Tuner zu Haupt-/PiP-Bild bleibt.) wechselt schnell von WDR SD zu ZDF SD.
• Im Hauptbild erscheint kurz "Tunen fehlgeschlagen!", erst danach wird von ZDF HD (SR 22000) zu  WDR HD (SR 27500) gewechselt.

• Ausgangssituation 2: Hauptbild wieder ZDF HD (SR 22000) / PiP-Bild Das Erste SD  SD (SR 27500)
• Rektion auf Fenstertausch:
• PiP-Bild  (Zuordnung der Tuner zu Haupt-/PiP-Bild bleibt wieder.) wechselt schnell von Das Erste SD zu ZDF SD.
• Im Hauptbild erscheint "Kanal nicht gefunden! (SID nicht in PAT gefunden)", Bild bleibt dauerhaft schwarz! Es wird also nicht von ZDF HD (SR 22000) auf Das Erste HD (SR 22000) getunt.
• Erneuter Fenstertausch (zurück zur Ausgangssituation): PiP- und Hauptbild erscheinen recht schnell.

Es passiert offenbar Folgendes:

• Der Befehl des Tuners, der für das PiP-Bild zuständig ist, kommt sofort zum Unicable-Router durch. Das PiP-Bild wechselt recht schnell.
• Hingegen wird der Befehl des für das Hauptbild zuständigen Tuners zunächst ignoriert. Die Reaktion darauf ist unterschiedlich:
• Soll auf einen Transponder mit einer anderen Symbolrate (SR) gewechselt werden, schlägt der Wechsel aber fehl, so lockt der Tuner nicht ein (> Meldung "Tunen fehlgeschlagen!"). Daraufhin wird das Unicable-Kommando wiederholt, und etwas verzögert erscheint auch das Hauptbild. Alles im Lot!
• Wenn aber auf einen Transponder mit gleicher Symbolrate gewechselt werden soll, der Wechselbefehl aber nicht beim Router ankommt, wird das nicht als solches registriert (> Meldung "Kanal nicht gefunden! (SID nicht in PAT gefunden)"), der Befehl wird nicht wiederholt, das Hauptbild bleibt schwarz. Dass sich am Unicable-Signal für den Hauptbild-Tuner nichts tut, erkennt man auch daran, dass nach erneutem Fenstertausch das Hauptbild sehr schnell erscheint; der Transponder lag ja die ganze Zeit an.

Zur Sicherheit habe ich das noch in einem simplen Testaufbau überprüft: Dazu wurde der Receiver über einen DC-Block mit dem Unicable-Router verbunden, so dass keine Befehle vom Receiver zum Router durchkommen können, zwischen DC-Block und Receiver noch ein simpler Testmonitor, der mit Leuchtdioden signalisiert, ob der Receiver ~13 V oder ~18 V bzw. 22 kHz-Signale ausgibt. An den LEDs kann man erkennen, ob ein Befehl gesendet wird oder nicht.

• Über ein zweites, ausnahmsweise auf dieselbe Adresse / Frequenz wie der ET programmiertes Empfangsgerät wird vom Unicable-Router der Transponder mit Das Erste HD angefordert. Der ET kann unter dieser Rahmenbedingung natürlich  Der Erste HD empfangen, auch wenn seine Befehle geblockt werden.
• Wechselt man auf einen Transponder mit der gleichen SR 22000 (Das kann auch ein DVB-S-/QPSK-Transponder sein.), so erkennt man am Testmonitor, dass sich der Receiver nach nur einem  Unicable-Kommando mit "Kanal nicht gefunden! (SID nicht in PAT gefunden)" begnügt.
• Wird hingegen auf einen Transponder mit anderer SR gewechselt, so dass der Tuner schon signaltechnisch nicht einlockt, erscheint die Meldung "Tunen fehlgeschlagen!", und es werden ständig neue Tuningbefehle ausgegeben.

Erstes, im Grunde genommen aber nicht entscheidendes Problem: Wenn beide Tuner zeitgleich auf einen anderen Transponder umtunen müssen, wird einer der beiden Befehle entweder gar nicht abgeschickt oder durch falsches Timing verschluckt. Für den PiP-Fenstertausch wäre das noch zu verschmerzen, aber im letztlich gleichen Fehlerbild kann das auch dazu führen, dass von zwei zeitgleich gestarteten Aufnahmen nur eine ausgeführt wird (Auch das habe ich so provozieren können.). Fehlschlagende Aufnahmen sind nicht mehr so einfach hinzunehmen.

Eigentlich liegt der Fehler aber tiefer als im Verschlucken eines von zwei gleichzeitig abgesetzten Kommandos eines Receivers. Denn dass ein Kommando nicht registriert wird, kann auch dann passieren, wenn nur ein Tuner eines Receivers den Transponder wechselt. Diese mögliche Nichtbeachtung eines Kommandos ist eine System-eigene Eigenschaft von Unicable! Denn es kann auch in einer völlig intakten Anlagenkonfiguration jederzeit passieren, dass zwei Receiver zeitgleich ein Kommando senden. Daher ist in der Einkabelnorm EN 50494 auch festgelegt, mit welchen Intervallen im Zweifelsfall ein Unicable-Kommando wiederholt werden muss. Wenn aber bereits nach nur einem Tuning-Kommando und in einer Situation, in der die nötigen Pakete im Datenstrom des Transponderns nicht gefunden werden, dann kein weiterer Befehl nachgeschoben wird, wenn der Tuner rein signaltechnisch (ohne Blick auf die Inhalte) einlockt, wird der für Unicable nötige Fehleralgorithmus nicht eingehalten!

Sorry für den Fall, dass das bereits ein alter Hund ist oder ich die entscheidende Einstellung übersehen haben sollte. Soweit ich gesucht habe, bin ich zwar über etliche Threads mit "SID nicht in PAT gefunden" gestolpert, dann aber mit einer generell nicht funktionierenden Unicable-Steuerung.

****

Noch etwas in Bezug auf Unicable:

Immer wieder kann man lesen, dass man das Plugin "satelliteequipmentcontrol" installieren und u.a. den Wert für "Delay after last diseqc command" von 50 auf 100 hochsetzen soll. Das hat bei mir so nur dann funktioniert, wenn der Receiver direkt mit dem Unicable-Router verbunden war. Hängt noch eine Userband-selektiv programmierbare Antennensteckdose dazwischen (Jultec JAP3xxTRS, Axing SSD 6-xx, ....),  war ein zuverlässiges Tuning nur mit Werten zwischen etwa 65 und 85 möglich. Ich hatte mich daraufhin dazu entschieden, den Mittelwert 75 als Einstellung zu übernehmen.