Ztw. kein Bild nach Umschalten mit VDR ab Version 2.3.9

  • Ich habe noch plugins mit altem Makefile


    vdr-User-# 755 to_h264 chk_r vdr-transcode github

  • Hallo,


    ich muss das Ganze hier leider noch mal aufwärmen.


    Bei mir tritt mit dem Commit "Now retuning if the received transponder's SDT doesn't contain the expected values for NID and TID" im VDR das Problem auf, das das erwartete Verhalten bei Aufnahmen nicht mehr funktioniert.


    Bisher war es so, das bei dem Problem "Data Stream Broken" während einer Aufnahme der VDR einen Neustart gemacht hat, das ist jetzt so nicht mehr unbedingt der Fall:


    Bei mir tritt sporadisch das Problem auf, das die DVB-Sky 952 nach längerer Zeit einen Kanal temporär nicht tunen kann. Im Falle einer Aufnahme, fast immer am Anfang, wurde dann ein "Data Stream Broken" erkannt, ein VDR Neustart gemacht und die Aufnahme war meistens noch in Ordnung.

    Mit dem Patch ist es nun so, das die gesamte Zeit einer Aufnahme diese Meldungen:


    SDT: channel 2 NID/TID (1/1019) not found, got 1/1019

    frontend 2/0 is not receiving transponder 111493 for channel 2 (Das Erste HD) - retuning


    erscheinen. Ein "Data Stream Broken" wird dadurch nicht erkannt und auch kein VDR Neustart gemacht. Die Aufnahme ist dann natürlich unbrauchbar.


    Ich habe mal ein gekürztes Log angefügt, das die Problematik verdeutlicht. Das das ein temporäres Problem ist, zeigt sich am Ende des Logs. Dort habe ich kurz die Aufnahme unterbrochen, das betroffene Device auf einen anderen Kanal geschaltet und dann die Aufnahme wieder gestartet. Danach war die restliche Aufnahme fehlerfrei.


    Viele Grüße

    kamel5

  • kamel5

    Das Problem - Datastream broken und Neustart, statt retune - hatte ich ja schonmal angesprochen...


    Der Neustart ist eigentlich noch ärgerlicher, so schreddert er hier in der Regel gleich zwei Aufnahmen, obwohl ein einfacher Retune (Channel +/-) gereicht hätte. Im Prinzip passiert also schon das Richtige, nur müßte das bei Nicht-Einkabel-Systemen "anders" retunen. Denke ich.


    Stefan

  • Naja, solange die Maßnahme zum Ziel führt, ist es prinzipiell egal, wie es gemacht wird.


    Du hast schon recht, das andere Aufnahmen bei Neustart betroffen sein könnten, aber in meinem Falle (siehe Log) bringt ein Retune keine Besserung, das geht dann solange, bis die Aufnahme zu Ende ist.


    Hier könnte man unter Umständen die Anzahl der Retunes begrenzen und dann immer noch einen Restart machen, wenn es nicht geholfen hat.


    Heute morgen hatte ich den Fall wieder und da sind mir gleich 2 Aufnahmen (nacheinander auf dem gleichen Kanal) durch das Retune "flöten" gegangen, da wäre mir ein Neustart lieber gewesen.


    So wie es jetzt ist, ist es aus meiner Sicht noch nicht 100% zufrieden stellend.


    obwohl ein einfacher Retune (Channel +/-) gereicht hätte.

    Er macht hier kein Channel+/-, zumindest ist das so im Log nicht erkennbar. Ein Channel+/- auf dem betroffenen Device würde in meinem Fall wahrscheinlich auch helfen, den ein händisches Channel+/- hilft bei mir. Danach funktioniert es wieder.


    Grüße

    kamel5

    VDR 2.6.6: ASUS Prime X470-PRO, Ryzen 7 5700X, 64GB, 6TB HD, GT1030, Fedora 39 Kernel 6.7 X86_64, Devicebonding 2 x 1 auf 2, TT6400, DVBSky S952 V3

    Git-Repo: gitlab.com/kamel5

  • Ich denke, das Problem liegt hier:

    Code
    void cSdtFilter::SetStatus(bool On)
    @@ -34,6 +39,7 @@ void cSdtFilter::SetStatus(bool On)
       sectionSyncer.Reset();
       if (!On)
          source = cSource::stNone;
    +  transponderState = tsUnknown;
     }

    Hier wird transponderState immer auf tsUnknown gesetzt - auch wenn gar kein Transponderwechsel erfolgt, wie z.B. bei einem Retune.

    Jetzt stellt sich die Frage, wie man den sdtFilter dazu bringt, einen Transponderwechsel zu erkennen. Es könnte irgendwie über cSectionHandler::SetChannel(const cChannel *Channel) gehen, dazu fehlen aber noch ein paar Codezeilen.


    Oder es wird die Transponder und Nid/Tid Prüfung doch in void cDvbTuner::Action(void) durchgeführt, da ist es etwas einfacher

    LG Helmut

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

  • Vielleicht geht es doch einfacher und es genügt diese Zeilen mit '+' in void cSdtFilter::SetStatus(bool On)einzufügen (nur frei hingeschrieben, nicht getestet):


    sectionSyncer.Reset();

    if (!On)

    source = cSource::stNone;

    + else {

    + if (Source() != lastSource | | !ISTRANSPONDER(Transponder(), lastTransponder)) { // transponder change

    + lastNid = 0;

    + lastTid = 0;

    + }

    +

    transponderState = tsUnknown;


    LG Helmut


    Edit: so kann es doch nicht gehen, da damit nicht mehr überprüft werden kann, ob der Transponder tasächlich gewechset wurde.

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

    Einmal editiert, zuletzt von HelmutB ()

  • kamel5: vielleicht hat es auch gar nichts damit zu tun, aber mir ist in deinem Log aufgefallen, dass zuerst mit dem Device 4 und etwas später auch mit Device 3 für die Aufnahme auf 'Das erste HD' geschalten werden. Das ist das gleiche Verhalten wie hier: vdr-mit-iptv-blockiert-bei-aufnahme-2-iptv-tuner-und-gibt-nur-einen-wieder-frei. Kannst du einmal den vdr-2.4.1-GetDeviceForTransponder.patch aus diesem Post dazunehmen und prüfen ob sich irgendetwas ändert.

    (Warum im Sectionhandler noch der Kanal 81 eingetragen ist, es aber schon die Daten von Kanal 2 empfangen werden, ist mir auch nicht klar)

    LG Helmut

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

  • HelmutB ,

    dass zuerst mit dem Device 4 und etwas später auch mit Device 3 für die Aufnahme auf 'Das erste HD' geschalten werden

    ich nutze hier Device-Bonding. Device 3 ist der Master und Device 4 ist der Slave. Vielleicht hat es ja damit was zu tun. Obwohl das ja auch kontraproduktiv wäre, zuerst den Slave zu schalten. ???

    Zumindest wurde laut Log vorher nicht das Device 3 getuned.

    Warum im Sectionhandler noch der Kanal 81 eingetragen ist,

    Das ist auch sehr seltsam, diesen Kanal hatte ich vorher nicht in Betrieb, möglicherweise EPG-Scan.

    Kannst du einmal den vdr-2.4.1-GetDeviceForTransponder.patch aus diesem Post dazunehmen

    Das habe ich jetzt mal gemacht.

    Jetzt muss ich halt auf das nächste Mal, bis dieses Problem nochmal auftritt, warten. Da das nur sporadisch auftritt, könnte das etwas dauern.


    Falls Du mehr Informationen zu diesem Log braucht, ich habe auch noch ein anderes Beispiel, sag bitte Bescheid, dann würde ich das die nächsten Tage mal aufbereiten.


    Viele Grüße

    kamel5

    VDR 2.6.6: ASUS Prime X470-PRO, Ryzen 7 5700X, 64GB, 6TB HD, GT1030, Fedora 39 Kernel 6.7 X86_64, Devicebonding 2 x 1 auf 2, TT6400, DVBSky S952 V3

    Git-Repo: gitlab.com/kamel5

  • Hallo kamel5!

    Ich sehe doch keinen Fehler im Commit "Now retuning if the received transponder's SDT doesn't contain the expected values for NID and TID" - es muß eine andere Ursache haben.


    Ich habe mir daher das DevivceBonding angesehen, bin aber nicht sicher ob ich alles verstanden habe da ich es derzeit wegen SCR auch nicht gut testen kann.

    Das mit BondedMaster und den slaves hat nicht mit einer Priorität zu tun, Die BondedTuners sind eine verlinkte Liste, Master wird ganz einfach das Device aus dieser Liste mit dem zum ersten mal cDvbTuner::SetChannel() aufgerufen wird.

    Die Diseqc-Commands werden nur mit dem Master durchgeführt und damit können über diesen immer die aktuellen BondingParameters abgefragt werden.
    Bei SetChannel() mit einem Slave und Änderung von Band/Polarization muß daher sowohl mit dem Master als auch mit dem Slave auf diesen Kanal geschalten werden.

    Und wenn ich es nicht ganz falsch verstehe könnte hier ein Problem entstehen, da der Sectionhandler immer aktiv ist. Dieser kennt den "channel" über cDevice::SetChannel(), bei cTuner::SetChannel() wird der "channel" des BondedMasterTuners aber am Sectionhandler vorbei geändert und auch darauf getuned. Es kommen daher andere Nid/Tid Pakete als im "channel" des Sectionhandlers stehen. Das Device des Bondedmaster wird eigentlcih gar nicht benötigt, aber die SDT-Daten landen trotzdem im Filter und werden von o.a. Commit verarbeitet.


    Ich hätte hier einen Patch, der verhindern soll, das der Master unnötig getuned wird. Das ganze ist aber eher ein Blindflug - ich weiß nicht zu 100% was ich hier tue und ob meine Annahme überhaupt stimmt...

    LG Helmut

  • Hallo HelmutB ,

    es muß eine andere Ursache haben.

    Das kann durchaus möglich sein. Mit dem Patch ist es das erste Mal so aufgetreten.

    Ob das Device-Bonding zu 100% richtig funktioniert, weiß ich auch nicht . Zumindest hat es in der Vergangenheit überwiegend funktioniert.

    Ob die manchmal aufgetretenen Probleme aber damit zusammen hingen, ist natürlich schwer nachvollziehbar. In der Vergangenheit hat dann der VDR ohne weitere Meldungen mit DSB einen Neustart gemacht. Vielleicht könnte da kls mehr dazu sagen.


    Zu den Patches:

    Im Moment habe ich es mit diesem Patch vdr-2.4.1-GetDeviceForTransponder.patch laufen, der Fehler ist bisher noch nicht wieder aufgetreten, was aber erst einmal nichts aussagt.

    Soll ich da jetzt den neuen Patch mit dazu nehmen oder den ersten dann weglassen?


    Viele Grüße

    kamel5

    VDR 2.6.6: ASUS Prime X470-PRO, Ryzen 7 5700X, 64GB, 6TB HD, GT1030, Fedora 39 Kernel 6.7 X86_64, Devicebonding 2 x 1 auf 2, TT6400, DVBSky S952 V3

    Git-Repo: gitlab.com/kamel5

  • Ich bin auch nicht sicher ob es wirklich an dieser Stelle des DeviceBondings liegt. Es ist aber so, dass manchmal mit dem BondedMaster kein echter Kanalwechsel durchgeführt wird sondern nur ein Tuning auf einen anderen Transponder. Die SectionFilter bekommen davon aber nichts mit.

    Das könnte zumindest erklären, warum bei dir von SectionFilter der Kanal 81 angezeigt wird, aber Nid/Tid von Kanal 2 kommen. Die Nid/Tid Prüfung und diese Meldung gibt es erst seit diesem Commit.


    Der GetDeviceForTransponder.patch versucht zu verhindern, dass bei Timeraufnahmen unnötigerweise 2 verschiedene Devices auf den gleichen Sender schalten. Die Aufnahme findet nur auf dem 2. freien Device statt, bei IPTV ist es aber deshalb störend, weil das 1. Device damit ein Zombie ist, der nicht aufhört Daten aus dem Internet zu ziehen.

    Ob er bei deinem Problen etwas hilft oder verbessert kann ich nicht sagen, schaden tut er auf keinen Fall.


    Ein Test nur mit dem switch-bonded-master.patch wäre aber eindeutiger (falls es damit überhaupt noch funktioniert).

    LG Helmut

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

  • OK, ich habe jetzt mal nur den Patch vdr-2.4.1-switch-bonded-master.patch in Betrieb. Bei ersten Tests hat es damit zumindest funktioniert. Ich werde das jetzt mal längerfristig beobachten, wie sich das im normalen Alltag verhält.


    Viele Grüße

    kamel5

    VDR 2.6.6: ASUS Prime X470-PRO, Ryzen 7 5700X, 64GB, 6TB HD, GT1030, Fedora 39 Kernel 6.7 X86_64, Devicebonding 2 x 1 auf 2, TT6400, DVBSky S952 V3

    Git-Repo: gitlab.com/kamel5

  • Da es grundsätzlich läuft - wenn irgendwann doch wieder ein Fehler auftritt wäre eine kurze Log-Meldung beim switchen des Bondedmaster für die Fehlersuche hilfreich. Deshalb hätte ich noch diese Zeile eingefügt:

    Code
    +           { // switch bonded master
    +           dsyslog("switch bonded master tuner from %d/%d (Ch.%d) to %d/%d (Ch.%d)", BondedMaster->adapter, BondedMaster->frontend, BondedMaster->channel.Number(), adapter, frontend, Channel->Number());
    +           bondedMaster = true;

    LG Helmut

  • Logging ist immer gut bei einer Fehlersuche...


    Ich habe jetzt den letzten Patch aktiv. Na, mal sehen.


    Viele Grüße

    kamel5

    VDR 2.6.6: ASUS Prime X470-PRO, Ryzen 7 5700X, 64GB, 6TB HD, GT1030, Fedora 39 Kernel 6.7 X86_64, Devicebonding 2 x 1 auf 2, TT6400, DVBSky S952 V3

    Git-Repo: gitlab.com/kamel5

    Einmal editiert, zuletzt von kamel5 ()

  • Hallo,


    ich nutze den device.patch nicht, aber ein schwarzes Bild nach dem Umschalten habe ich hier schon länger nicht gesehen.


    HelmutB , mit dem Patch vdr-2.4.1-switch-bonded-master2.patch habe ich bisher keine Auffälligkeiten festgestellt. Die oben genannten fehlerhaften Aufnahmen sind bisher auch nicht mehr aufgetreten.

    Ich werde das jetzt mal längerfristig beobachten.


    Viele Grüße

    kamel5

    VDR 2.6.6: ASUS Prime X470-PRO, Ryzen 7 5700X, 64GB, 6TB HD, GT1030, Fedora 39 Kernel 6.7 X86_64, Devicebonding 2 x 1 auf 2, TT6400, DVBSky S952 V3

    Git-Repo: gitlab.com/kamel5

  • Ich nutze auch den device.patch von xblades und den vdr-2.4.1-test-check-scr-06-fix3.diff ... bisher funktioniert es sehr gut.

    kls Hattest du Dir den device.patch vom User xblades inzwischen angeschaut?

  • Hattest du Dir den device.patch vom User xblades inzwischen angeschaut?

    Danke für den Hinweis, den hätte ich fast aus den Augen verloren.


    Ich habe mir das jetzt mal näher angeschaut. Die Änderung in Version 2.3.9 diente

    ja dazu, einen möglichen Deadlock zu verhindern. Dazu wurde von Lock()/Unlock(),

    was ja den gesamten Thread lockt, auf ein lokaleres Locking mit mutexReceiver

    umgestellt. Dadurch kam aber das Receiver->Activate(false), welches vorher nicht

    mit im Lock war, in den neuen Lock hinein. User xblades hat also wohl vollkommen Recht,

    es da wieder herauszuholen. Allerdings würde ich gern den mutexReceiver nicht

    bei jedem Schleifendurchlauf locken/unlocken, sondern einfach das Receiver->Activate(false)

    und die umliegenden Zeilen aus der Schleife rausnehmen, was auf das Gleiche

    hinauslaufen sollte.

    Bitte schaut euch mal beiliegende Version des Patches an und testet damit.

Jetzt mitmachen!

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