Ztw. kein Bild nach Umschalten mit VDR ab Version 2.3.9

  • Aktuell nutze ich diese hier:

    Code
    S19.2E  11700 V  9750  t V W20 S0 [71 00 00 00] W20 v
    S19.2E  99999 V 10600  t V W20 S1 [71 00 00 00] W20 v
    S19.2E  11700 H  9750  t V W20 S2 [71 00 00 00] W20 v
    S19.2E  99999 H 10600  t V W20 S3 [71 00 00 00] W20 v

    Gruß

    Uwe

  • ich habe den Patch aus #11 von xblades bei mir eingebaut, und endlich sind die z.T. sekundenlangen Verzögerungen beim schnellen Durchzappen weg. Ein schwarzes Bild hatte ich dabei eigentlich so gut wie nie, aber es nervte extrem, dass mancher Kanalwechsel mehrere Sekunden dauerte. Ich hoffe, kls kann sich das rasch anschauen und vielleicht eine Version 2.4.2 veröffentlichen.

    VDR1: ACT-620, Asus P8B75-M LX, Intel Core i3-3240, 4 GB DDR3 RAM 1600 MHz, passive Geforce GT1030 von MSI, Sandisk 2TB SSD, 2xWinTV DualHD, Atric-IR-Einschalter. SW: Xubuntu 20.04 auf 64GB Sandisk SSD.

    VDR2: Odroid N2+ mit CoreELEC und Ubuntu in chroot, WinTV DualHD

    VDR3: Tanix TX3 mit CoreELEC und Ubuntu in chroot, WinTV DualHD

  • Das schwarze Bild kommt bei folgender Situation (bei Unicable)


    1. Ein externer Receiver zieht die Leitung auf 18V und schaltet um (z.B ein anderer VDR während er EPG scannt)


    2. Es wird ein Sender eingestellt welcher die gleichen Transpondereinstellungen hat wie der vorige. (Modulation & Symbolrate bleiben gleich). Der Tuner liefert ein Hardware Lock und VDR ist glücklich.


    Sofern der neue Transponder eine andere Modulation & Symbolrate hat und VDR kein Lock bekommt versucht VDR den Transponder erneut zu tunen (also die Diseqc Befehle erneut abzusetzen).


    3. VDR hängt nun auf dem falschen Transponder rum, der liefert zwar Daten aber nicht die richtigen.


    Dies wurde mittels folgendem Befehl überprüft (folgender Befehl analysiert den Transportstream der aktuell übermittelt wird, die Befehle greifen auf die Interne Schnittstelle bei den Sundtek Tunern zu):

    /opt/bin/mediaclient --tsscan /dev/dvb/adapter0/dvr0


    4. Unser Treiber loggt die Diseqc Befehle, wenn Uwe die Befehle manuell absetzt (also ein Re-Tune wie bei einem fehlendem Lock durchführt) bekommt er ein Bild.


    /opt/bin/mediaclient -V H

    /opt/bin/mediaclient --diseqc "aa bb cc dd ee"

    /opt/bin/mediaclient -V V


    ("aa bb cc dd ee" nimmt er aus unserer Logfile, was VDR halt geschickt hat)


    Die SDT (Service Description Table) sollte überprüft werden ob der eingestellte Sender auch wirklich auf dem Transponder vorhanden ist. Falls nicht sollte der Transponder wie bei Punkt 2 behandelt werden (=re-tune)

    https://en.wikipedia.org/wiki/Service_Description_Table


    Das Problem tritt wohl sehr selten auf.


    --- und hier noch wie Uwe es reproduziert hat ---


    Jetzt habe ich wieder nachgestellt:

    Code
    Apr  1 16:07:42 raspberrypi vdr: [2028] switching to channel 26 S19.2E-1-1039-10378 (SR Fernsehen HD)
        Apr  1 16:07:42 raspberrypi vdr: [2217] device 1 TS buffer thread ended (pid=2028, tid=2217)
        Apr  1 16:07:42 raspberrypi vdr: [2216] buffer stats: 389348 (7%) used
        Apr  1 16:07:42 raspberrypi vdr: [2216] device 1 receiver thread ended (pid=2028, tid=2216)
        Apr  1 16:07:43 raspberrypi vdr: [2031] frontend 0/0 locked on channel 26 (SR Fernsehen HD), tp 111053 after 284 ms
        Apr  1 16:07:43 raspberrypi vdr: [2218] device 1 receiver thread started (pid=2028, tid=2218, prio=high)
        Apr  1 16:07:43 raspberrypi vdr: [2219] device 1 TS buffer thread started (pid=2028, tid=2219, prio=high)


    Mit dem mediaclient-Tool geschaut, was empfangen wird:

    hr-fernsehen HD war der Sender, der davor eingestellt war.


    Jetzt schaue ich in Logfile, was der Sundtek Treiber für ein Diseqc Kommando für hr-fernsehen HD abgesetzt hat:



    Sobald ich das Diseqc Kommando abgesetzt hatte (2), war sofort ein Bild auf sr-fernsehen HD zu sehen. Das sieht man auch im syslog: rpihddevice: set...


    Code
    Apr  1 16:10:53 raspberrypi vdr: [2218] rpihddevice: set video codec to H264
    Apr  1 16:10:53 raspberrypi vdr: [2043] rpihddevice: set HDMI audio output format to 2ch PCM, 48.0kHz
    Apr  1 16:10:54 raspberrypi vdr: [2042] rpihddevice: video stream started 1280x720@50p, PAR=1/1
    Apr  1 16:10:54 raspberrypi vdr: [2042] rpihddevice: display PAR=1,000, setting video render PAR=1/1
  • Ich weiß nicht ob das hier mit reinspielt, aber ich hatte in der Vergangenheit auch schon kaputte Aufnahmen bei meinem SCR/Unicable Setup.


    Ich habe dann EPG-Scan ausgeschaltet und das schien zu helfen. Ich würde aber nicht ausschließen das es nicht EPG war sondern eventuell sogar ein anderer Receiver an der gleichen Leitung.

  • Ich weiß nicht ob das hier mit reinspielt, aber ich hatte in der Vergangenheit auch schon kaputte Aufnahmen bei meinem SCR/Unicable Setup.

    Danke für den Hinweis. :)

    Dieses Problem habe ich nicht und tritt nur auf, wenn die Unicable (also Kabel, Splitter ohne Dioden, End-Dosen, Splitter mit Dioden usw.)-Installation fehlerhaft ist.

    Die Dioden vor dem Tuner, sollten eine Störung auf einem andere Receiver oder VDR´s verhindern... verhindern aber nicht, dass eventuell zwei Receiver zur gleichen Zeit einen Diseqc-Befehl senden...

    Wenn erstmal der Sender eingestellt ist, egal welches Devices, treten hier keine Störungen auf...

  • Hier nochmal als komplettes Log (mit Ausgabe des Sundtek Treiber und des syslog)!


    Ich schaltet auf ONE HD (14:06:17), dass Bild bleibt schwarz (14:06:18), setze 18V (14:07:09), setze manuell nochmal das Diseqc Kommando ab (14:07:37) und setze wieder 13V (14:07:44)!


    Ab 14:07:37 habe ich wieder ein Bild!


    Aktuell laufen 2x VDR über ein Unicable Kabel....


    Gruß

    Uwe


  • Sundtek Kann man sich darauf verlassen, dass ein ioctl()-Aufruf an den Treiber erst dann zurückkehrt, wenn das Signal-Handling auf der Antennenleitung vollständig erledigt ist? Oder ist es möglich, dass der Treiber da was puffert und asynchron abarbeitet?


    Ich frage deshalb, weil innerhalb eines VDR ja durch einen Mutex sichergestellt ist, dass immer nur *ein* Tuner die Leitung benutzt. Was aber nicht funktionieren würde, wenn der Treiber asynchron arbeitet.


    Sobald ein weiteres Gerät die gleiche Leitung benutzt (anderer VDR oder Receiver) besteht die Möglichkeit einer Kollision natürlich unabhängig davon und bedarf einer Lösung im VDR.

  • Sobald ein weiteres Gerät die gleiche Leitung benutzt (anderer VDR oder Receiver) besteht die Möglichkeit einer Kollision natürlich unabhängig davon und bedarf einer Lösung im VDR.

    Zur Info: Ich habe dieses "Blackscreen"-Problem nur, wenn ein zweiter VDR eingeschaltet ist, der auch per Unicable auf dieser Koaxleitung angeschlossen ist.

  • Uwe : versuche es einaml mit einer längeren Verzögerung nach dem setzen von 18V und vor dem zurückschalten auf 13V, z.B 100ms: S19.2E 11700 V 9750 t V W100 S0 [71 00 00 00] W100 v

    Helmut

    HelmutB passed unfortunately away on July 21, 2022 ... RIP 🖤

  • Sundtek Kann man sich darauf verlassen, dass ein ioctl()-Aufruf an den Treiber erst dann zurückkehrt, wenn das Signal-Handling auf der Antennenleitung vollständig erledigt ist? Oder ist es möglich, dass der Treiber da was puffert und asynchron abarbeitet?


    Ich frage deshalb, weil innerhalb eines VDR ja durch einen Mutex sichergestellt ist, dass immer nur *ein* Tuner die Leitung benutzt. Was aber nicht funktionieren würde, wenn der Treiber asynchron arbeitet.


    Sobald ein weiteres Gerät die gleiche Leitung benutzt (anderer VDR oder Receiver) besteht die Möglichkeit einer Kollision natürlich unabhängig davon und bedarf einer Lösung im VDR.

    Ist synchron. Es geht im Fall von Uwe soweit ich weiß auch um 2 oder mehrere Systeme die auf der Unicable Leitung sitzen.

  • Uwe : versuche es einaml mit einer längeren Verzögerung nach dem setzen von 18V und vor dem zurückschalten auf 13V, z.B 100ms: S19.2E 11700 V 9750 t V W100 S0 [71 00 00 00] W100 v

    Helmut

    Die längere Verzögerung blockiert die 18V doch nur noch länger auf der Leitung (für den anderen Teilnehmer). Nehmen wir an dass der 2. Teilnehmer gerade EPG scannt... da wird eine Kollision dann schon deutlich wahrscheinlicher.


    Wenn VDR 2 nun folgende Dinge einstellt während der VDR 1 die Leitung oben hat

    Alter Transponder Symbolrate: 22msym; Modulation QPSK

    Neuer Transponder Symbolrate: 22msym; Modulation QPSK


    Tuner wird da dann ein OK und Locked zurückgeben, egal ob der LNB nun den Transponder wechseln konnte oder nicht - und genau das passiert hier.


    Wenn VDR 2 von 22msym; Modulation QPSK auf 27.5MSYM/8PSK wechseln würde dann würde der Tuner im nachfolgendem Schritt kein Hardware-Lock zurückgeben und der VDR würde versuchen Diseqc erneut abzuschicken.

  • Uwe : versuche es einaml mit einer längeren Verzögerung nach dem setzen von 18V und vor dem zurückschalten auf 13V, z.B 100ms: S19.2E 11700 V 9750 t V W100 S0 [71 00 00 00] W100 v

    Hallo Helmut,


    wenn nur ein VDR-System aktiv ist, gibt es keine Probleme beim Tunen mit mehreren Tunern (hier ein Dual Tuner), außer die Zeiten sind zu gering. Ich kann, wie weiter oben gepostet, mit Zeiten W20/W20 arbeiten ohne Probleme. Um hier aber Probleme auszuschließen, bin ich aktuell bei W20/W40... (W100/W100 hatte ich aber auch schon...)

    Ich kann mir die Finger Wund zappen ;) , es kommt zu keinem Blackscreen... :) ...sobald aber ein zweiter Receiver/VDR dazu kommt (ja, beide VDR mit aktiven EPG-Scan, den möchte ich nicht missen) kommt es in selten Fällen zum „Blackscreen“...


    Gruß

    Uwe

    Einmal editiert, zuletzt von Uwe ()

  • Es wäre als Test gedacht. Ich könnte mir vorstellen, dass die Command-Bytes nicht vollständig zum LNB gelangen weil entweder beim Senden der Command Bytes die 18V noch nicht aufgebaut sind oder weil danach zu schnell auf 13V zurückgeschalten wird. Ich habe das bei meiner TBS5520 festgestellt, da braucht es mind. ein W50 vor dem Zurückschalten auf 13V, W20 ist zu kurz.

    Helmut

    Uwe . habe dein Post zu spät gelesen - hilft bei dir also nicht.

    HelmutB passed unfortunately away on July 21, 2022 ... RIP 🖤

  • Uwe . habe dein Post zu spät gelesen - hilft bei dir also nicht.

    Ich hatte mit höheren Werten auch getestet, deinen Post in einem anderen Thread habe ich gelesen, aber das löst nicht das Problem... und verlängert die Zapping-Zeiten :)

  • Das obige logdiseqc.diff zeigt nur die Ausführung der Diseq Befehle der im jeweiligen VDR vorhandenen Tuner, nicht aber die von anderen VDRs oder STBs und ist daher nicht sehr nützlich.

    Wie Sundtek oben beschrieben hat, weiß man trotz LOCK nicht, ob der Diseqc Befehl ordnungsgemäß durchgeführt wurde, oder ob der Transponder aufgrund einer Datenkollision gar nicht geändert wurde.

    Was ich so gelesen habe um bei einem Transponderwechsel so eine Kollision zu erkennen bzw. auszuschließen ist es, zuvor einen "Unlock" zu erzwingen indem das Userband mit einem "ODU_PowerOFF" in den Standbymodus geschaltet wird. Bei einem Lock nach dem darauffolgenden "ODU_Channel_change" oder Jess "Tuning" Befehl kann dann mit sehr hoher Wahrscheinlichkeit davon ausgegangen werden, das nun der richtige Transponder eingestellt ist.

    Ich nehme an, dass die Idee von Klaus auch in diese Richtung geht.


    Helmut


    HelmutB passed unfortunately away on July 21, 2022 ... RIP 🖤

  • Meine Idee geht mehr in die Richtung, die tatsächlichen Daten zu checken.


    Der beliegende Patch prüft, ob die gewünschte SID in der PAT enthalten ist und löst einen Retune aus, wenn sie nicht innerhalb von 2 Sekunden gefunden wird. Eine hunderprozentige Lösung ist das freilich auch nicht, denn unterschiedliche Transponder können die selben SIDs verwenden. Eventuell müssen noch weitere Daten mit einbezogen werden (am liebsten ja die Transponder-ID, aber da habe ich auf die Schnelle keine Stelle gefunden, wo man sicher sein kann, die ID des tatsächlich getunten Transponders zu erhalten - falls da jemand drauf deuten kann, bitte her damit!).


    Bitte probiert es mal damit. Aber Achtung: der Patch ist experiementell und hat noch einige Debug-Ausgaben. Das soll nur mal ein erster Ansatz sein...

  • kls : Da war ich etwas zu langsam, ich wollte dir nämlich gerade eine Email schreiben.


    Ich habe hier einen Patch der mit ODU_PowerOff arbeitet.

    Es wird dazu vor einem Programmwechsel und wenn bereits ein Lock anliegt, eine "PowerOff" Sequenz gesendet. Damit gibt es kein Signal und auch keinen Lock mehr auf diesem SCR-Channel. Dieses Kommando wird erforderlichenfalls auch mehrmals gesendet, da es ja auch dabei zu einer Datenkollision kommen kann.

    Danach wird ganz normal auf den neuen kanal umgeschalten, und ein Wechsel von "Unlock" zu "Lock" zeigt, dass die diseqc-Sequenz fehlerfrei übertragen wurde. Falls es doch eine Datenkollision gegeben hat, und der gewünschte Transponder nicht eingestellt werden konnte, wird - wie sonst auch ohne Lock - nach einer Sekunde ein neuer Tuningversuch gestartet.


    ich habe ihn nur ohne echte Kollisionen prüfen können, aber vom System her scheint er zu funktionieren.

    Vielleicht kann man ja beide Patches kombinieren.

    Helmut

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!