[markad] überarbeiteter Decoder

  • Doch es kommt, nur halt ... viel später als gedacht.

    Mir scheint, er hat erst mit/nach der nächsten Aufnahme weiter gemacht:


    Es könnte sein, das das Suspend-Video nach 3h stört, gucke die Logs gleich mal durch...


    Stefan

  • Code
    Tue Jun 22 09:05:25 [22088] INFO:  paused by signal
    Tue Jun 22 17:05:00 [22088] INFO:  continued by signal

    Wow, 8h Pause, warum das ???

    Es könnte sein, das das Suspend-Video nach 3h stört

    Was ist das ?


    Poste bitte mal ein markad.log und ein dazu gehöriges syslog (grep auf markad, vdr mit -l3 starten) und die setup.conf (auch grep auf markad).

    Er scheint ja wohl korrekt loszulaufen (Tue Jun 22 09:05:23 [22088] INFO: continued by signal), wird dann aber kurz darauf wieder für 8h schlafen geschickt. Das ist seltsam ...

  • Ursächliches Problem ist offenbar eine Unterbrechnung der Aufnahme "durch Signalverlust".


    Das macht ein Patch von HelmutB (vdr-2.4.7-SignalMonitoring2.patch). Ob es einen realen Signalverlust gab (Sat-Schüssel), die DVB-S Karte bisweilen spinnt, oder der Patch zu nervös ist, läßt sich nicht sagen.


    Es unterbricht die Aufnahme aber kurz, dann geht es weiter. Danach kommt markad durcheinander (Aufnahme doppelt). Eine spätere Aufnahme (es lief morgens nichts parallel) wurde sofort korrekt bearbeitet ...


    Setup:


    Grep auf Markad (und das Syslog zur Aufnahme morgens anbei).


    Grüße,

    Stefan

  • Es unterbricht die Aufnahme aber kurz, dann geht es weiter. Danach kommt markad durcheinander (Aufnahme doppelt).

    Ja, das glaube ich auch, in der Ecke müssen wir suchen. Ich werde da aber aus dem Log nicht schlau, wo es hängt. Ich baue dir mal in den nächsten Tagen eine Debug Version, wo man mehr sieht. Ideal wäre dann ein Test, wo nur eine Aufnahme läuft, dann lässt sich das Log einfacher lesen.

  • Fourty2

    bitte teste mal mit dem branch. Ich glaube, ich habe den Fehler gefunden: Wie du schon vermutet hast, startet das Plugin bei jeder kurzen Unterbrechung der Aufnahme einen neuen markad Prozess auf die gleiche Aufnahme. Damit kommt die Verwaltung der aktiven Prozesse durcheinander, weil die Prozesse für den resume über den Namen der Aufnahme gesucht werden, die dann mehrfach vorkommt.

    Ich kann das leider nicht testen, weil ich die Unterbrechung nicht simulieren kann. Bitte auch wenn es gehen sollte ein syslog (grep markad) posten, damit ich sehen kann, ob es sich so verhält, wie ich das vorgesehen habe.

  • Beim Markad-Resume scheint die Prüfung die Zahl der noch wartenden Prozesse falsch (-1) zu berechnen. Sobald die zweite Aufnahme (Stunden später gestartet) beendet wird, werden beide Prozesse wiederaufgenommen, bearbeitet und beendet:


  • Beim Markad-Resume scheint die Prüfung die Zahl der noch wartenden Prozesse falsch (-1) zu berechnen.

    Verstehe ich nicht, was meinst du damit ?


    Edit: Und du hast die Spielregeln geändert, jetzt ist ein richtiger Crash drin. Das muss ich mir mal näher anschaut, woher das Plugin die laufenden Prozesse wieder herbekommt.


    Code
    Jun 24 02:45:00 roadrunner vdr: [3823] markad: cStatusMarkAd::Recording(): recording <(null)> [/srv/vdr/video/local/Becky/2021-06-24.00.35.101-0.rec] stopped
    Vom Plugin Suspendoutput:
    (Schwarzbild, Last der integrierten Graphik abwerfen, falls nur Aufnahmen laufen ...)
    Jun 24 03:43:16 roadrunner vdr: [3823] suspendoutput: output suspended by inactivity timer

    Die Aufnahme war 02:45:00 beendet und es lief keine andere Aufnahme mehr. Richtig ?

    Hier hätte der Resume kommen sollen, aber der kommt nicht. Ich suche ...

    Einmal editiert, zuletzt von kfb77 ()

  • Bitte nochmals testen mit dem branch, ich habe nochmals ein paar Debug Logs beim Stop vom Recording eingefügt.

    Ich habe wohl mit dem ersten Versuch ein Problem gelöst, aber nicht deines. ;)

    Inzwischen habe ich den Verdacht, dass bei dir nach der Aufnahme Unterbrechung das Device belegt bleibt und damit markad davon ausgeht, dass immer noch eine Aufnahme läuft. Das werde ich dann mit den neuen Logs sehen.

    Einmal editiert, zuletzt von kfb77 ()

  • a) "Verstehe ich nicht, was meinst du damit ?"


    Die erste Aufnahme (auch nach (Timer-)Neustart des VDR-Systems), bleibt im Zustand "Pause", bis das Ende der zweiten Aufnahme das Resume auslöst, scheint mir.


    Vermutung: Indexfehler (ab 0 und ab 1). Habe aber dazu im Code so direkt nichts gefunden (kurz geguckt).


    b) "Edit: Und du hast die Spielregeln geändert, jetzt ist ein richtiger Crash drin."


    Weiblicher VDR... :)


    c)

    Ja, es lief eine Aufnahme, dann hätte der VDR abschalten sollen, was er nicht tat, sondern erst nach der zweiten Aufnahme nachmittags.


    Stefan

  • Vermutung: Indexfehler (ab 0 und ab 1). Habe aber dazu im Code so direkt nichts gefunden (kurz geguckt).

    Jetzt verstehe ich das. Ich habe länger geguckt und auch nichts gefunden. Aber du hast Recht, das Verhalten ist genau so, als ob markad meint, da läuft noch eine Aufnahme. Darum jetzt mein Verdacht, dass der Patch, den du drin hast, das Device nach der Unterbrechung nicht mehr (oder nicht schnell genug) frei gibt. Aber das werden wir ja an deinem nächsten Test sehen, ich log das damit mit.

    Das würde auch erklären, warum am nach dem Ende der nächsten Aufnahme alle markad Prozesse loslaufen: Bei deiner Konfiguration (kein markad während Aufnahme) werden am Ende der Aufnahme (und wenn keine andere Aufnahme läuft) alle schlafenden markad Prozesse wieder resumed, nicht nur der eigene.

    Soweit die Theorie, das nächste Log wird es zeigen ...

    a, es lief eine Aufnahme, dann hätte der VDR abschalten sollen, was er nicht tat, sondern erst nach der zweiten Aufnahme nachmittags.

    Das ist auch eine interessante Info. Das kann die gleiche Ursache haben, weil der VDR meint, da ist noch ein Device belegt. Ich prüfe das ja auch nur mit VDR Mitteln.

    Code
    int cStatusMarkAd::Recording() {
        int cnt = 0;
        for (int i = 0; i < cDevice::NumDevices(); i++) {
            cDevice *dev = cDevice::GetDevice(i);
            if (dev) {
                if (dev->Receiving()) cnt++;
            }
        }
        return cnt;
    }
  • Das macht ein Patch von HelmutB (vdr-2.4.7-SignalMonitoring2.patch). Ob es einen realen Signalverlust gab (Sat-Schüssel), die DVB-S Karte bisweilen spinnt, oder der Patch zu nervös ist, läßt sich nicht sagen.

    Wenn es während der Aufnahme zu einem Signalverlust kommt, solltest du zuerst so eine Meldung im syslog sehen:

    frontend 1/0 lost lock on channel....

    Erst wenn danach 11 Sekunden lang kein Signal kommt, versucht der SignalMonitoring-Patch für Livebild oder Aufnahme auf ein anderes freies Device umzuschalten. Zu sehen mit No signal on tp xxx for channel... und retuning due to modification of channel....

    Du kannst es testen, indem du das Antennenkabel abziehst.

    LG Helmut

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

  • HelmutB ,

    vielen Dank für deine Unterstützung bei der Fehlersuche. Vorbehaltlich dass mein Verdacht stimmt, wäre das wohl die fragliche Stelle im ungefiltertem syslog (messages.gz von weiter oben):

    An der Stelle sehe ich im markad log, dass die Aufnahme abgebrochen und neu gestartet wird. Die Frage ist nun, ob Receiving() vom abgebrochen Device ab da false liefert ? Ein "frontend 1/0 lost lock on channel...." finde ich nicht im syslog.

  • Ich sehe schon, da muss ich beim SignalMonitoring Patch nachbessern. Hier gibt es keinen "Lost Lock" sondern es kommt 1 Sekunde lang keine PAT - deshalb das (vermutlich) unnötige Retune.

    Mir ist das bei meinen Tests nie untergekommen, ich werde es mir morgen genauer ansehen.


    Zum Receiving(): Bei einer Aufnahme auf einem ungültigen Transponder mit Retune sieht es - zumindest im syslog - bei mir so aus, dass zuerst der receiver thread auf dem neuen Device(2) gestartet und dann der auf dem alten Device(3) beendet wird.

    Du kannst der Sache ja grundsätzlich nachgehen, aber ich glaube, mit einem verbesserten SignalMonitoring Patch wird zumindest bei Fourty2 keine Änderung in markad notwendig sein.

    LG Helmut

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

  • HelmutB

    Die Fehler in den Aufnahmen waren der Grund, warum ich das Markad mal testhalber von während auf nach der Aufnahme umgestellt habe. Hatte zunächst die Last in Verdacht, aber ...


    kfb77

    ... nichtsdestotrotz ist da in Bug in der Taskverwaltung der sich finden wird:

    Aktuelles Log von Nachtaufnahmen / 2 Stück / VDR noch an, obwohl idle. Diesmal alles dabei, von PID-Update, über SignalMonitoring bis Neustart. :-}


    @Webserver:

    Zeige die max. 10k Zeichen doch mal in der Vorschau an, Danke...


    Stefan

  • nichtsdestotrotz ist da in Bug in der Taskverwaltung der sich finden wird

    Das sehe ich nicht so, das Log bestätigt doch meinen Verdacht:

    Code
    Jun 25 02:44:24 roadrunner vdr: [9326] markad: cStatusMarkAd::Recording(): index 0, pid 9562, filename /srv/vdr/video/local/Horizon_Line/2021-06-25.02.35.100-0.rec: recording stopped
    Jun 25 02:44:24 roadrunner vdr: [9326] markad: cStatusMarkAd::RunningRecording(): running recording on device 0
    Jun 25 02:44:24 roadrunner vdr: [9326] markad: cStatusMarkAd::RunningRecording(): 1 running recordings
    Jun 25 02:44:24 roadrunner vdr: [9326] markad: cStatusMarkAd::Recording(): resume not possible, still 1 running recordings

    In dem Abschnitt (der sich sinngemäß mehrmals wiederholt) sieht man, dass die Aufnahme abgebrochen wird, das device 0 danach aber immer noch belegt meldet. Folge davon ist, dass markad nicht weiterläuft, was natürlich auch den VDR shutdown verhindert. Ich vermute, das wird so lange so bleiben, bis eine Aufnahme auf device 0 ohne Unterbrechung durchläuft und danach das Device ordnungsgemäß freigegeben wird.

    Die Task Verwaltung stimmt so, er wartet, bis nach Ende der Aufnahme kein Device mehr belegt ist. Und HelmutB bestätigt ja auch das Verhalten:

    Zum Receiving(): Bei einer Aufnahme auf einem ungültigen Transponder mit Retune sieht es - zumindest im syslog - bei mir so aus, dass zuerst der receiver thread auf dem neuen Device(2) gestartet und dann der auf dem alten Device(3) beendet wird.

    Und genau die Reihenfolge ist das erste Problem: Das Plugin wird am Ende der Aufnahme getriggert, da muss schon das device frei sein, nicht erst nach dem Start auf dem nächsten Device.

    Und das zweite Problem ist: Das Log sieht so aus, als ob das device nie freigegeben wird, weil ja auch am Ende der letzten Aufnahme immer noch ein device belegt ist.

    Code
    Jun 25 06:15:00 roadrunner vdr: [10010] markad: cStatusMarkAd::Recording(): index 1, pid 10149, filename /srv/vdr/video/local/Tin_Cup/2021-06-25.03.30.109-0.rec: recording stopped
    Jun 25 06:15:00 roadrunner vdr: [10010] markad: cStatusMarkAd::RunningRecording(): running recording on device 0
    Jun 25 06:15:00 roadrunner vdr: [10010] markad: cStatusMarkAd::RunningRecording(): 1 running recordings
    Jun 25 06:15:00 roadrunner vdr: [10010] markad: cStatusMarkAd::Recording(): resume not possible, still 1 running recordings
    Jun 25 06:15:27 roadrunner vdr: [10010] markad: cStatusMarkAd::Replaying called, start recording <NULL>
    Jun 25 09:15:27 roadrunner vdr: [10010] markad: got shutdown request
    Jun 25 09:15:27 roadrunner vdr: [10010] markad: markad is running for recording Horizon Line, defere shutdown
    Jun 25 09:15:27 roadrunner vdr: [10010] markad: markad is running for recording Tin Cup, defere shutdown

    Das ist nach dem Ende der letzten Aufnahme: VDR will shutdown, aber device 0 meldet immer noch belegt und somit kann markad entsprechend deiner Konfiguration die Prozesse nicht weiter laufen lassen.

    Mal sehen, was HelmutB dazu sagt.


    Edit: Die Reihenfolge, wäre wahrscheinlich sogar egal, das korrigiert sich am Ende der letzten Aufnahme, das eigentliche Problem ist, das es auch am Ende der Aufnahme nicht mehr freigegeben wird.

  • Jun 25 02:44:24 roadrunner vdr: [9326] markad: cStatusMarkAd::Recording(): index 0, pid 9562, filename /srv/vdr/video/local/Horizon_Line/2021-06-25.02.35.100-0.rec: recording stopped
    Jun 25 02:44:24 roadrunner vdr: [9326] markad: cStatusMarkAd::RunningRecording(): running recording on device 0
    Jun 25 02:44:24 roadrunner vdr: [9326] markad: cStatusMarkAd::RunningRecording(): 1 running recordings
    Jun 25 02:44:24 roadrunner vdr: [9326] markad: cStatusMarkAd::Recording(): resume not possible, still 1 running recordings


    In dem Abschnitt (der sich sinngemäß mehrmals wiederholt) sieht man, dass die Aufnahme abgebrochen wird, das device 0 danach aber immer noch belegt meldet.

    Die Aufnahme auf Adapter 0 (bei dir Device 0) ist aber schon das neue Device. Die abgebrochene Aufnahme lief zuvor auf Adapter 1:

    Im kompletten syslog sollte man auch die SignalInfo nach dem Device-Switch sehen können.

    LG Helmut

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

  • Die Aufnahme auf Adapter 0 (bei dir Device 0) ist aber schon das neue Device. Die abgebrochene Aufnahme lief zuvor auf Adapter 1:

    Ja, das passt ja: Zuerst wird die neue Aufnahme gestartet, dann die alte beendet. Wenn ich dann beim Beenden der alten Aufnahme aufgerufen werde, sehe ich schon die neue Aufnahme laufen. Das wäre ja kein Problem.


    Die Frage ist, was passiert ab 06:15 Uhr, warum ist da nach Ende der letzten Aufnahme immer noch das device 0 belegt ?

    Code
    Jun 25 06:15:00 roadrunner vdr: [10010] markad: cStatusMarkAd::RunningRecording(): running recording on device 0

    Fourty2 : Bitte poste mal das vollständige Log ab 06:14 Uhr.

  • Danke, mal sehen ob HelmutB da drin was sehen kann, ich kann es nicht.

    mit einem verbesserten SignalMonitoring Patch wird zumindest bei Fourty2 keine Änderung in markad notwendig sein.

    Ich kann an dem Stand jetzt nichts mehr beitragen und warte auf den o.g. Patch. Du kannst ja mal bei Gelegenheit ohne den Patch testen um zu sehen, ob dann vom VDR am Ende der Aufnahme alle Device als frei zurückgegeben werden.

Jetzt mitmachen!

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