[VDR 2.3.8] Timer-Aufnahme unterbrochen und läuft dann endlos weiter

  • Hallo,


    ich hoffe, ich bin hier an der richtigen Stelle. Ich habe dieses Problem auch schon im KODI Forum gepostet, da ich meinen VDR 2.3.8 auf Ubuntu 16.04 zusammen mit KODI 17.3 als Fontend betreibe. Der Entwickler von VNSI meint aber, dass es sich hier eher um ein VDR Problem handelt.


    Kurz, worum geht es:


    Ich habe eine Timer-gesteuerte Aufnahme erstellt:

    Code
    1. Sky Cinema Comedy - Taxi 22.08.2017 from 04:42 to 06:20

    Diese wird auch pünktlich um 04:42 Uhr begonnen, wird dann aber bereits um 06:11 beendet. Offenbar - wenn ich das Log richtig lese - weil es Änderungen am Kanal des aufgenommenen Programs gab.

    Nur wenige Sekunden danach startet der VDR die Aufnahme erneut (im selben Aufnahmeverzeichnis), beendet die Aufnahme aber nicht Timer-konform um 06:20 Uhr, sondern setzt die Aufnahme bis in den Nachmittag fort. Bis ich das bemerke und schließlich das System neustarte.


    Ein Abbrechen der Aufnahme auf KODI heraus war zu dem Zeitpunkt nicht möglich (Fehler wird angezeigt) und im syslog steh dannt:

    Code
    1. Aug 22 17:24:00 localhost vdr: [2775] ERROR: video data stream broken
    2. Aug 22 17:24:00 localhost vdr: [2775] initiating emergency exit

    Auch das Aufrufen des VDR OSD über die Client-Spezifischen Einstellungen im KODI Setup ist dann nicht mehr möglich (System reagiert nicht darauf), weshalb ich mir nur über den Reboot zu helfen wusste.


    In der Aufnahme ist ab Zeitpunk 06:11 Uhr nur noch ein schwarzes Bild zu sehen. Davor wurde normal aufgezeichnet.

    Angehängt, das Syslog für den relevanten Zeitraum.


    Das Verhalten tritt nicht immer auf. Aktuell ist es das zweite Mal, nachdem ich kürzlich auf VDR 2.3.8 und CAM-Betrieb aktualisiert habe.

    Ich bin für jeden Hinweis dankbar, wie man das ggfs. umgehen kann oder - falls es ein Bug ist - wie ich beim weiteren Troubleshooting helfen kann.


    Bisher war ich von der Kombi VDR/KODI, die bei mir seit Monaten (fast) problemlos läuft, völlig begeistert.

  • Da wird wohl die Methode der verwendeten Software-Entschlüsselung reinspielen, was, das sage ich gleich dazu, hier leider nicht besprochen werden kann. Im Prinzip gibt es aber eh nur eine die wirklich fehlerfrei mit VDR 2.3.8 läuft, hier den letzten GIT Stand verwenden.


    Das Problem der gestoppten Aufnahmen durch Änderungen der PIDs des aufgenommen Senders während der Aufnahme wurde eigentlich im Developer 2.3.x Zweig behoben, ich kannte das auch nur von verschlüsselten Sendern und habe es seit der spezifischen Änderung nicht mehr gesehen.


    Regards

    fnu

    HowTo: APT pinning

  • Softwareentschlüsselung nutze ich nicht. Bei mir ist eine DD Cine S2 v5.5 mit angeschlossenem Flex CI und CAM im Einsatz. Mit VDR 2.3.8 nutze ich das DDCI2-Pugin in der letzten Version (1.0.5). Ich hoffe, dass dieses Setup hier erlaubt ist (sehe ich zumindest in vielen Signaturen).


    Ich hab versucht, auch in alten Threads zu lesen und war auch der Meinung, dass dieses Problem eigentlich nicht mehr auftreten sollte... vielleicht ist dies hier ein Sonderfall/Exot, der bisher nicht betrachtet wurde.


    Ich nutze im VDR noch einen Patch speziell in Verbindung mit dem CI, den Klaus selber hier vorgeschlagen hatte: CI-Unterstützung für CineS2, Mystique SaTiX-S2 Dual usw.


    Den Abbruch aufgrund der geänderten PIDs kann ich ja noch nachvollziehen, aber dass die Aufnahme endlos weiterläuft und die Timersettings komplett ignoriert finde ich "strange".

  • aber dass die Aufnahme endlos weiterläuft und die Timersettings komplett ignoriert finde ich "strange".

    Ja, da hast Du recht, aber ich kenne das so nicht. Hatte in früheren Jahren etliche Aufnahmen, die abgebrochen wurden wegen PID Änderung, aber niemals hat der VDR selbstständig nachgelegt. Daher ganz offen, ich würde hier KODI/vnsi nicht ausnehmen, weil das steuert und überwacht m.E. den Timer, den Du auch über Kodi gesetzt hast, oder?


    Da die Verlängerung dann ausschließlich schwarz war, hat jedenfalls Deine Entschlüsselung nimmer funktioniert, das könnte das Hängen des VDR erklären ...


    DDCI2 kann hier besprochen werden, aber bitte keine (!) Erwähnung des verwendeten CAM. Danke.


    Regards

    fnu

    HowTo: APT pinning

  • Welche Plugins sind denn da noch aktiv? Sieht man Meldungen wegen einer falsche Lock-Reihenfolge im Log?

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • An Plugins laufen bei mir, neben ddci2 (1.0.5), noch streamdev-server (0.6.1-git), vnsiserver (1.5.2) und wirbelscan (2017.06.04)

    Meldungen wegen falscher Lock-Reihenfolge sehe ich keine im Log.


    Genau, den Timer habe ich über Kodi angelegt. Aber auch währen der Verlängerung war immer nur der eine Timer mit den korrekten Start-und Endzeiten aktiv. Hatte auch erst vermutet, dass kodi einen neuen Timer angelegt hat, war aber nicht so.


    Ich meine sogar, dass es beim ersten Mal eine Aufnahme auf einem FTA Sender war. Da hab ich es aber noch für einen "Ausrutscher" gehalten. Dass es jetzt zum zweiten Mal innerhalb kurzer Zeit auftritt, macht mir etwas Sorgen.


    Wen man sich das syslog anschaut, bin ich überhaupt erstaunt, wieviele "changing pids of channel" Meldungen auch aktuell man dort in kurzen Intervallen findet (über alle Sender, FTA und verschlüsselt). War mir vorher gar nicht so aufgefallen.

  • Nach 06:11:14 ist es im Log von VDR-Seite verdächtig ruhig. Ich würde mal vermuten, daß die Hauptschleife irgendwo hängengeblieben ist.


    Startest du VDR mit Watchdog (Option -w)?

    Wenn nicht, dann setze den mal auf z.B. 60 Sekunden.


    Klaus

  • Man könnte sich auch mal mit gdb attach $(pidof vdr) an den VDR-Prozess hängen, wenn er in dem Zustand ist und nachsehen, was er zuletzt gemacht hat (die debug-Symbole sollte da natürlich nach Möglichkeit installiert sein).

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • Startest du VDR mit Watchdog (Option -w)?

    Wenn nicht, dann setze den mal auf z.B. 60 Sekunden.

    Aktuell starte ich den VDR ohne watchdog (-w 0). Werde ihn mal auf 60 Sekunden einstellen.


    Ich werde heute Abend mal ein paar Aufnahmen planen, um zu sehen, ob ich das Problem reproduzieren kann. Tritt bisher leider nur sporadisch auf.

    (die debug-Symbole sollte da natürlich nach Möglichkeit installiert sein).

    Kannst Du kurz was dazu sagen, was dafür bzw. wie das genau installiert werden muss?


    Danke Euch!

  • Das hängt davon ab, aus welcher Quelle du deinen VDR hast - bei den yaVDR-VDR Paketen sind die in vdr-dbg und vdr-plugin-<pluginname>-dbg ausgelagert, wenn du den VDR selber kompiliert hast, sollten die Symbole dabei sein, wenn gcc mit -g aufgerufen wurde (was im Makefile bzw. der Make.conf standardmäßig eingestellt ist).

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • Ok. Danke.


    Dann sollte das bei mir der Fall sein, da ich den VDR selber kompiliert habe. Jetzt heißt es abwarten bis es wieder auftritt. Erste Aufnahme ist reibunglos durchgelaufen...


    Edit: Murphys Law; Alle Aufnahmen sind bisher korrekt durchgelaufen. Auch die Bildfehler sind aktuell bei den Aufnahmen minimal. Vielleicht war es doch nur ein (zwei) Ausreißer.

  • Heureka. Bei der letzten Aufnahme heute Nacht, ist es wohl wieder passiert.

    Durch den jetzt aktivierten Watchdog wurde der VDR aber neu gestartet und hat dann die Aufnahme wie geplant beendet.


    WIe es aussieht, so war es auch beim letzten Mal, tritt das Problem unmittelbar nach Ende des Films auf, wenn Sky auf "Werbung" schaltet. Sky scheint dann irgendwas am Signal/Datenstrom zu ändern, was das System aus dem Tritt bringt.


    Der Timer war so eingestellt:

    Code
    1. Sky Cinema Action - Batman v Superman: Dawn of Justice 26.08.2017 from 05:42 to 08:20


    Der Film lief laut EPG von 05:45 bis 08:15 Uhr.


    Ich hoffe der Auszug aus dem Syslog für den relevanten Zeitraum hilft den Fehler einzukreisen:

  • Um den Fehler einzukreisen (sollte er im VDR-Core liegen) müsstest du erstmal die Plugins streamdev, vnsiserver und wirbelscan weglassen. Wenn dann der Fehler immer noch auftritt, liegt er entweder im ddci2-Plugin oder in VDR selber.


    Klaus

  • Auf streamdev und wirbelscan kann ich verzichten. MIt vnsiserver ist das schwieriger, da dann mein Frontend nicht mehr verfügbar ist und ich keine Möglichkeit mehr habe, auf den VDR zuzugreifen. Das würde leider auch den WAF auf den Gefrierpunkt abkühlen lassen


    Ich will nicht vorgreifen, aber ich fürchte, dass der Fehler tatsächlich mit dem ddci2 Plugin irgendwie zusammenhängt. Ich nutze das Plugin erst seit kurzem (ca. 3 Wochen) während ich den VDR, auch in der Verison 2.3.8, schon länger betreibe und vorher keine Probleme hatte.


    Im Thread zum ddci2-Plugin habe ich ja bereits gepostet, dass sich meine ältere Cine S2 v5.5 mit CI Modul nicht so 100% mit dem Plugin verträgt - was evtl. auch am Support für den ngene Treiber liegen kann. Wenn es läuft, läuft es richtig gut, aber mit den Aussetzern zwischendurch macht es gerade nicht so wirklich Spaß.


    Ich hab mir bereits eine Cine S2 v6.5 geschossen und warte nun auf deren Eintreffen in der Hoffnung, dass die Unterstützung für die Treiber dieser Version (ddbridge) besser ist.


    Update: Es bleibt schwierig. Die neue Cine S2 v6.5 wird vom Mainboard nur sporadisch erkannt. Fehler scheint bekannt und ist leider nicht lösbar. Also erstmal alte Karte wieder rein und mit den gelegentlichen Aussetzern leben und dann Sparschwein füttern, um den geplanten HW-Upgrade für Mainboard/CPU/Speicher vorzuziehen. Mann oh Mann, ich hoffe die Investition lohnt sich ...