Posts by kfb77

    kls

    Wir sind jetzt ein wenig weitergekommen: Die Id 2863 im o.g. Log ist gar nicht markad, sondern VDR. Der Channel Lock kommt vom VDR, der Timer Lock von markad, in dieser Reihenfolge. So weit so schlecht.

    Eigentlich dachte ich immer, der VDR führt Plugin Methoden immer in einem eigenen Thread aus und somit hat jedes Plugin sein eigenes Lock Universum. Dem ist offensichtlich nicht so.

    Aber jetzt meine Frage: Darf der VDR einen Lock haben, wenn er eine Plugin Methode aufruft ? Ich kann mir nicht vorstellen, dass das gut ist, dann laufe ich im Plugin ja blind in einen Sequenz Fehler rein, oder ?

    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 ;-)

    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
    1. Jan 3 09:41:56 vdr: [2863] retuning: TMR, CHN Read Lock
    2. Jan 3 09:41:56 vdr: [2863] stopping recording due to modification of channel 101
    3. Jan 3 09:41:56 vdr: [2863] SendCaPmts CAM 1: [1] actives in CAM: 2 -> 1 (3 pids)
    4. Jan 3 09:41:56 vdr: [2863] CAM 1: unassigned from device 2
    5. Jan 3 09:41:56 vdr: [2863] NALU fill dumper: 77771 of 3031629 packets dropped, 2%
    6. Jan 3 09:41:56 vdr: [2863] buffer stats: 484476 (0%) used
    7. Jan 3 09:41:56 vdr: [2863] timer 35 (101 0935-1145 '#1') stop
    8. 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.

    Ungetesteter Vorschlag:

    Aus dem cTimer Objekt den Filename holen mit File(), dann aus cRecordings mit GetByName(Filename) das zugehörige cRecording.

    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.

    Plugin wird trotzdem nicht erkannt, ist aber in /usr/lib/vdr/plugins vorhanden.

    Zeige mal vdr --version.

    Es werden grundsätzlich nur Plugins geladen, die auch ein Konfigfile in /etc/vdr/conf haben. Gibt es da ein File für markad mit mindestens dem Inhalt "[markad]" ?

    Edit: Wird wohl auch ohne Konfig File geladen.

    Hallo kls

    ich bräuchte mal deinen Support. Fourty2 bekommt diesen invalid lock sequence report:

    Das Problem ist ja wohl der Channel Lock vor dem Timer Lock bei markad.

    Mein Problem ist, dass markad keinen Channel Lock an der Stelle macht, zumindest finde ich ihn nicht. Es gibt nur eine Stelle im markad Code, der einen Channel Lock macht, der wird aber nur aus dem Konfigurations Menu aufgerufen. Außerdem ist er mit Debug Meldungen versehen, siehe hier, die wie erwartet, nicht im Log auftauchen.


    Meine Frage: Gibt es irgendwas anderes, außer "cChannels::GetChannelsRead(StateKey)" und LOCK_CHANNELS_READ, was implizit einen Channel Read Lock macht ? Wo kommt mein Lock her ?


    Das Problem ist reproduzierbar nach dem Abbruch einer Aufnahme wegen PID Änderung:

    Code
    1. Jan 3 09:41:56 vdr: [2930] changing pids of channel 1862
    2. Jan 3 09:41:56 vdr: [2934] changing pids of channel 101
    3. Jan 3 09:41:56 vdr: [2930] changing pids of channel 1862
    4. Jan 3 09:41:56 vdr: [2863] retuning: TMR, CHN Read Lock
    5. Jan 3 09:41:56 vdr: [2863] stopping recording due to modification of channel 101
    6. Jan 3 09:41:56 vdr: [3303] recording thread ended (pid=2863, tid=3303)
    7. Jan 3 09:41:56 vdr: [2863] SendCaPmts CAM 1: [1] actives in CAM: 2 -> 1 (3 pids)
    8. Jan 3 09:41:56 vdr: [2863] CAM 1: unassigned from device 2

    Weitere Details und Logs ab hier im markad Thread.

    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.

    sm->Recording(Device, Name, FileName, On);

    Ja, das ist der Aufruf, der dann in markad zum Timer Lock führt, das war mir bekannt.


    Aber wo ist der Aufruf, der in markad zum Channel Lock führt ?

    Da müsste der VDR ein Objekt cOsdItem vom Plugin erzeugen, siehe markad setup.h

    Code
    1. class cSetupMarkAdListItem : public cOsdItem

    Und ich finde den Aufruf nur, wenn man im markad Konfigurationsmenu in der Zeile "nur Kanäle mit Logo scannen" die blaue Taste drückt. Nur so schaffe ich es bei mir einen Channel Lock zu bekommen. Eine PID Änderung einer laufenden Aufnahme kann ich nicht künstlich erzeugen.

    Es kann natürlich sein, das die Installationsreihenfolge der Plugins hinein spielt

    Das glaube ich eigentlich nicht, der Fehler:

    vdr: [2869] 2869 - R - - - - - - - - L
    vdr: [2869] 2869 R * - - - - - - - - L

    ist rein markad intern. Aber "glauben" kommt von "nicht Wissen".

    der VDR die Statusmonitore der Plugins bearbeitet

    An der Stelle, wo der Fehler auftritt, wird ChannelChange der Plugins aufgerufen. markad hat aber gar keine Methode ChannelChange, sollte also gar nicht aufgerufen werden.

    Viel Glück beim Reproduzieren und vor allen möchte ich einen Channel Lock im Syslog sehen.

    Habe noch einen Patch zum Testen drin

    Bitte nicht zwei Änderungen gleichzeitig, das macht es mir nur schwerer.

    Hatte mal zum Test ein LOCK_CHANNELS_READ vor den Timers-Lock in Zeile 49x geschrieben

    Der Ansatz ist mal einen Test wert, aber umgekehrt: Einen Timer Lock vor dem Channel Lock. Channel Lock vor Timer Lock ist nicht zulässig, muss umgekehrt sein.

    Was ich gar nicht verstehe, ist dass in deinem Syslog gar kein Channel Lock von markad drin ist. VDR behauptet aber, den würde es geben.


    Ich habe noch mehr debug Nachrichten eingebaut, bitte nochmals mit dem Branch "lock" testen. Syslog bitte ab sein paar Zeilen vor dem Channel Lock von markad ("cSetupMarkAdList(): WANT channels READ"), hoffentlich kommt diesmal einer.