[markad] überarbeiteter Decoder

    Das habe ich mich ja auch schon gefragt (dazu der offensichtlich illegale Channels-Lock oben).


    Das einzige plausible wäre, daß der VDR bei ChannelChange was gelockt hält, was er bei manuellem Stop/Start nicht tut.


    Die nächsten PID Änderungen kann ich zwar relativ sicher vorhersagen (lach), Du bräuchtest dafür nur ein passendes Abo nebst CI Hardware - die, nunja, vom Anbieter nicht mehr heiß und innig geliebt wird. Das geht also nicht mehr. ;)


    Ich baue jetzt um die Stelle im VDR Core Lock/Release Ausgaben ein. Vielleicht sieht man was.


    Stefan

    Zitat von Fourty2

    Das einzige plausible wäre, daß der VDR bei ChannelChange was gelockt hält, was er bei manuellem Stop/Start nicht tut.

    Das würde aber keine invalid lock sequenz innerhalb markad erzeugen. Das könnte aber dafür sorgen, dass markad channel read lock nicht bekommt (warum auch immer er den haben will ???) und er somit nicht im Syslog auftaucht. Dann würde alleine der Versuch des Locks schon von VDR mit der Fehlermeldung bestraft (was eigentlich auch Sinn macht). Aber das werden wir ja jetzt mit den "WANT ... lock" debug Meldungen sehen, die vor dem eigentlich Lock drin sind.

    Hab eben zur zweiten Aufnahme kurz ins Log geschaut ... alles bestens.

    Das Ding bringt mich um ... :-/


    Sagte der VDR: "Hab ich doch längst erledigt": :)


    Jetzt hätte ich gedacht, Timers wäre die zuerst zu lockende Liste, und mehrere READ-Locks möglich. Aber offenbar stimmt das so generell nicht.


    Mit aktiviertem originalem Lock-Debugging mag der VDR nicht - GPF. Blöd.


    Stefan

    Zitat von Fourty2

    Hab eben zur zweiten Aufnahme kurz ins Log geschaut

    Jetzt klingeln aber ein paar Alarmglocken: Bleibt da ein Channel Lock von der ersten Aufnahme hängen ? Wie gesagt, suche mal ab VDR Start, da muss irgendwo ein Channel Lock drin sein.

    Leider ...



    (grep markad + Backtrace)

    Sehe da im Plugin-Code auch nichts.


    Außer vielleicht, das man "Locks-Requests" ohne Timeout immer bekommt (nur wann, halt) und deshalb die if (Timers) entbehrlich sein dürften.


    Aber das ist ja alles sauber durchgelaufen. Dem parallel laufenden epg2vdr hab ich auch schon ein unnötiges Timer Writelock in ein Lesendes geändert, aber ... keine Ahnung. :wow


    Die Edith-Idee:


    Das einzige wäre halt:


    Ein Thread [2863] aus Lock-Sicht:
    Jan 3 09:41:56 vdr: [2863] retuning: TMR, CHN Read Lock

    Jan 3 09:41:56 vdr: [2863] markad: RunningRecording(): WANT timers READ


    [2863] Locked (aus vdr.c) erst Timers, dann Channels, ruft Funktion in Markad (auch [2863]) auf, der Timers erneut lockt -> daher Fehler, wegen TMR > CHN > TMR ?

    Zitat von Fourty2

    Locked (aus vdr.c) erst Timers, dann Channels, ruft Funktion in Markad (auch [2863]) auf, der Timers erneut lockt

    Das sollte korrekt sein, weil Sequenz Error sich immer nur ein Plugin beziehen. Was der VDR vorher macht, oder andere Plugins machen, spielt keine Rolle. Genau darum gibt es ja die vorgegebene Reihenfolge, damit sich die Locks irgendwann auflösen können und keinen Dead Lock erzeugen.

    Ich mag mich irren, aber wenn ich mir dem Programmcode ansehe, der den "invalid lock sequence report" erzeugt, also:


    void cStateLockLog::Check(const char *Name, bool Lock, bool Write)

    (in thread.c:641)


    dann erlauben die Locks nur, das unterschiedliche Threads (ggf. konkurrierend) Lesend auf die Listen zugreifen können, und die Daten per "nur ein Thread schreibt, wenn keiner anderer liest" konsistent bleiben.

    Die Reihenfolge muß bei allen gleich und FILO (bz. FLLU) sein - klar.


    Aber im Code steht m.E.: gleicher Thread darf nur jeweils einmal in bekannter Reihe locken

    Code
    if (Lock) {
if ((flags[Index] & ~b) < b) // thread holds only "smaller" locks -> OK
;
else if ((flags[Index] & b) == 0) // thread already holds "bigger" locks, so it may only re-lock one that it already has!
DoDump = true;
logCounter[Index][n]++;
flags[Index] |= b;
}
else if (--logCounter[Index][n] == 0)
flags[Index] &= ~b;


    Und Thread war immer 2863 - der unten im VDR seine Kreise zog. Dieser hatte schon Channels gelockt, so daß Timers locken den Report auslösen müßte (Timers nicht "bigger"). Aber warten wir auf kls ...


    Stefan.

    Ja, da bin ich bei dir. Und laut dem Backtrace sollte 2863 der markad Thread sein und der macht keinen Channel Lock.

    Was mir dabei gerade auffällt, wo kommen denn diese Meldungen her ? Von markad sind sie nicht.

    Code
    Jan  3 09:41:56 vdr: [2863] retuning: TMR, CHN Read Lock
Jan  3 09:41:56 vdr: [2863] stopping recording due to modification of channel 101
Jan  3 09:41:56 vdr: [2863] SendCaPmts CAM 1: [1] actives in CAM: 2 -> 1 (3 pids)
Jan  3 09:41:56 vdr: [2863] CAM 1: unassigned from device 2
Jan  3 09:41:56 vdr: [2863] NALU fill dumper: 77771 of 3031629 packets dropped, 2%
Jan  3 09:41:56 vdr: [2863] buffer stats: 484476 (0%) used
Jan  3 09:41:56 vdr: [2863] timer 35 (101 0935-1145 '#1') stop
Jan  3 09:41:56 vdr: [2863] removing /srv/vdr/video/local/#1/2022-01-03.09.35.101-0.rec/.timer

    Und die erste Zeile sieht auch nach dem gesuchten Channel Lock aus. Aber warum unter der gleichen Thead ID wie markad ??? Das wird ja immer seltsamer.

    Der VDR selbst ist/war PID/Thread [2863]:


    Code
    Jan  3 09:26:33 vdr: [2863] VDR version 2.4.7 started
Jan  3 09:26:33 vdr: [2863] switched to user 'vdr'
Jan  3 09:26:33 vdr: [2863] codeset is 'UTF-8' - known


    Die Lock-Ausgabe kommt daher: :S

    Zitat von Fourty2

    Ich baue jetzt um die Stelle im VDR Core Lock/Release Ausgaben ein. Vielleicht sieht man was.


    Stefan


    Die sind jetzt dort:

    vdr.c:1071 (+/- andere Patche)



    Das sieht, für mich, so aus, als ob das markad-Plugin, zumindest da, keinen eigenen Thread startet.


    Grüße,

    Stefan

    Zitat von kfb77

    Jan 3 09:41:56 vdr: [2863] retuning: TMR, CHN Read Lock

    Wo kommt denn diese Zeile her ? Im original VDR Code ist die nicht drin, welcher Patch ist das ?

    Verdacht: Der Patch macht einen Channel Lock und keinen Unlock bevor der VDR Plugin Methoden (Recording()) aufruft. Ich kann mir nicht vorstellen, dass das zulässig wäre, weil sich dann die Lock Reihenfolge nicht mehr kontrollieren lässt. Ups, genau das ist ja unser Problem ;)

    Zitat von kfb77

    Wo kommt denn diese Zeile her ? Im original VDR Code ist die nicht drin, welcher Patch ist das ?

    Verdacht: Der Patch macht einen Channel Lock und keinen Unlock bevor der VDR Plugin Methoden (Recording()) aufruft. Ich kann mir nicht vorstellen, dass das zulässig wäre, weil sich dann die Lock Reihenfolge nicht mehr kontrollieren lässt. Ups, genau das ist ja unser Problem ;)

    Das ist mein Debug-Patch, der anzeigt, daß der VDR sich selbst ein, zwei Locks besorgt, bevor er die PID-Änderung bearbeitet:

    (Vorauslaufende '.' = Leerzeichen - blöder Editor/Browser. isyslog tiefer im 'if' wegen Logspam :) )


    Und nein, die Stelle ändert kein Patch:


    Camtweaks und HideFirstRecordingLevel ändern die Schleife nicht - geprüft:

    Zu finden (ohne Debug isyslog) in vdr.c ab Zeile 1038. Die Locks holt sich der VDR ganz original:


    HTH,

    Stefan

    Bitte teste mal mit dem Patch gegen vdr im Anhang. Ich nehme mal testweise den Channel Lock vor dem Aufruf von cRecordControls::ChannelDataModified(Channel) weg und setze ihn danach wieder. Das wird sicher nicht die finale Lösung sein, ist als Test gedacht, ob das wirklich die Ursache ist.

    Ja, ist es. Soll ja auch nur feststellen, ob es wirklich genau an dem Lock liegt und das hoffentlich vor einem Crash. Wenn das funktioniert, können wir das Problem qualifizierter bei kls adressieren.

    Du hast gesehen, es gab nochmals einen Update vom Patch.

    Lange lebt er damit nicht ... der VDR. :-]

    (Selbst ganz ohne Aufnahme - das käme erst gegen 20:15)


Jetzt mitmachen!

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

Benutzerkonto erstellen Anmelden