2 replies to this topic

[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.

[hounce]

Hallo,

 

ich verwende ebenfalls Unicable am ET9x00. In meiner Konstellation (Inverto Unicable LNB) passiert der Fehler lediglich ein paar mal pro Jahr, bisher ist es daher auch noch nie passiert, dass bei mir deshalb eine Aufnahme fehlgeschlagen ist.

 

Aber ich danke Dir für die genaue Ursachenforschung. Das PLi-Team sollte wissen, ob die ausbleibende Befehls-Wiederholung im Fehlerfall in der Verantwortung von Enigma2 steht, oder eine Aufgabe des Treibers ist. Ist es ersteres, bin ich zuversichtlich, dass das auch gefixt werden wird.

 

Intuitiv würde ich aber denken, dass das eher eine Sache des Treibers ist. In diesem Fall müsste die Problembeschreibung daher an die Entwickler der Treiber weitergeleitet werden, was ich versuchen werde.

 

Grüße

Hounce

[raceroad]

Danke für Deine Antwort!

 

In meiner Konstellation (Inverto Unicable LNB) passiert der Fehler lediglich ein paar mal pro Jahr, bisher ist es daher auch noch nie passiert, dass bei mir deshalb eine Aufnahme fehlgeschlagen ist.

 

Zugegeben: Nachdem ich das Verhalten beim PiP-Fenstertausch verstanden hatte, konnte ich es mir nicht verkneifen, eine fehlschlagende Aufnahme zu provozieren. Aber erstens halte ich die Konstellation mit zwei zeitgleich startenden Aufnahmen und bereits aktivem Tuner nicht für total an den Haaren herbeigezogen, und zweitens bleibt einfach festzuhalten, dass das für Unicable systembedingt (= mehrere Tuner an einem Kabel) notwendige Kollisionsmanagement in doppelter Hinsicht nicht korrekt umgesetzt wird: Einerseits wird ein fehlgeschlagenes Tuning nicht immer bemerkt und folglich auf die nötige Wiederholung des Tuning-Befehls verzichtet, andererseits wird dann, wenn ein fehlgeschlagenes Tuning festgestellt wurde, der Befehl zu oft wiederholt (Die erlaubte Anzahl der Wiederholungen ist klar geregelt!).

 

Intuitiv würde ich aber denken, dass das eher eine Sache des Treibers ist. In diesem Fall müsste die Problembeschreibung daher an die Entwickler der Treiber weitergeleitet werden, was ich versuchen werde.

 

Im Einkabelstandard sind verschiedene Methoden aufgeführt, wie ein verworfener Befehl festgestellt werden kann. Eine davon setzt nahe am "SID nicht in PAT gefunden" an: Die SID kann auch nach erfolgtem Tuning nicht gefunden werden, wenn sich die Belegung des Transponders geändert hat und eignet sich daher nicht, um einen ignorierten Befehl zu erkennen. Was sich aber auch im Fall einer geänderten Nutzung des Transponders nicht ändert, ist seine TSID (transport stream id). Die TSID steht zur Verfügung (> Hauptmenü > Informatrionen > Kanal > PIDs), so dass ich an dieser Stelle nicht sehe, dass es an Treiberunterstützung mangelt, um durch eine sich nach einem Tuning-Befehl nicht ändernde TSID zu erkennen, dass das Tuning fehlgeschlagen ist.