[epg2vdr] Invalid lock sequence?

    Habe ein wenig rumprobiert und mir ist nun im Log folgendes aufgefallen:

    Passiert bei Programmübersicht.

    Im Skin flatPlus erden die Gruppen falsch angezeigt; könnte das davon kommen?


    Edit: Log mit Level 3 eingefügt und Bild ergänzt

    So sieht es aus, wenn ich mis skinLCARSNG teste via live

    Die doppelte Slashes in den Pfaden zu den Files - im ersten Log Zeile 3 und 5 - schauen komisch aus, oder?

    MyVDR: yaVDR-Ansible (Ubuntu 20) - softhddevice-openglosd (ffmpeg 2.8) - epgd/epg2vdr - skindesigner estuary4vdr (adaptiert) - 1920x1080@50 Hz | kodi 18 - inputstream + amazon vod
    Aerocube M40 | 300W | ASRock H61M-GE | Intel G530 | Asus ENGT520 | 2 x TT-budget S2-3200 | ASRock Smart Remote (CIR) | 4 GB RAM | 120 GB SSD | 3 TB HDD

    Sollte kein Problem sein

    Code
    darkwing@darkwing-PC ~ $ cd .local//bin
darkwing@darkwing-PC ~/.local/bin $

    Ich habe das aber jetzt im Skin trotzdem mal geändert.

    Remove extra '/' in LoadLogo · MegaV0lt/vdr-plugin-skinflatplus@8816236
    github.com

    Aus dem ersten "begin invalid lock sequence report" kannst Du ableiten, das in cFlatDisplayMenu::SetItemEvent() ein

    "LOCK_CHANNELS_READ" gemacht wird. Da es aber dort vom VDR schon einen "LOCK_SHEDULES_READ" gibt, bekommst Du hier diese Meldung, weil dadurch die Reihenfolge der LOCKs nicht stimmt. Das kannst Du auch in dieser Funktion nicht auflösen.

    Die richtige Reihenfolge der LOCKs ist 1.Timers, 2. Channels, 3. Recordings, 4. DelRecordings und 5. Shedules.


    Ich habe mir angewöhnt keine LOCKs in den Set* Funktionen, die direkt vom VDR aufgerufen werden, zu benutzen.

    Was kannst Du also tun: das was den "LOCK_CHANNELS_READ" braucht, aus dieser Funktion auszulagern und dann über cFlatDisplayMenu::Flush() bereitzustellen, wie das mit "LOCK_TIMERS_READ" auch schon gemacht wird.

    cFlatDisplayMenu::Flush() enthält keine vom VDR ausgehenden LOCKs.


    Beim zweiten "begin invalid lock sequence report" scheint der Skin nicht involviert zu sein, da das direkt von Live zu kommen scheint. Hier wäre auch die Reihenfolge von "LOCK_SHEDULES_READ" und danach "LOCK_TIMERS_READ" falsch.


    Grüße

    kamel5

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

    Git-Repo: gitlab.com/kamel5

    Gefällt mir 1

    Hab noch mal mit VDR Skin getestet

    Der Fehler kommt da auch.

    Ich habe den Lock sequence nur im Menüpunkt scraper2vdr-Programm.

    An meinem VDR läuft ein Script, das auf Locksequence prüft. Bin mir also sicher, dass es nur in Verbindung mir scraper2vdr kommt.

    Betrifft vermutlich alle Skins?

    Vielen Dank für die schöne Erklärung. Ich begreife das aber nicht. Umsetzen kann ich das auch nicht ;(

    Zitat von MegaV0lt

    Der Fehler kommt da auch.

    Ich habe den Lock sequence nur im Menüpunkt scraper2vdr-Programm.

    An meinem VDR läuft ein Script, das auf Locksequence prüft. Bin mir also sicher, dass es nur in Verbindung mir scraper2vdr kommt.

    Das kann dann auch nur da oder in Live behoben werden.

    Zitat von MegaV0lt

    Vielen Dank für die schöne Erklärung. Ich begreife das aber nicht. Umsetzen kann ich das auch nicht ;(

    OK, kein Problem. Ich habe mal kurz geschaut, den LOCK brauchst Du ja nur, um die max. Channelnummer (Channels.MaxNumber()) festzustellen, wegen der Zeichenbreite.

    Der einfachste Weg wäre hier, eine feste Breite anzunehmen, z.B. 4 Stellen:

    Möglich wären sicher auch noch viele andere Varianten, dann müsste man sich aber doch intensiver damit beschäftigen...


    Da der "invalid lock sequence report" immer nur beim ersten Auftreten entsteht, dieser Code aber noch in anderen Set* Funktionen benutzt wird, musst Du das dann auch an den anderen Stellen noch ändern.


    Grüße

    kamel5

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

    Git-Repo: gitlab.com/kamel5

    Danke 1

    Vielen Dank. Das schau ich mir die Tage dann mal genauer an. Aber der Vorschlag erscheint mit doch "vernünftig". Ich denke nicht, dass jemand mehr als 9.999 Kanäle in der Liste hat

    Zitat von kamel5

    Da der "invalid lock sequence report" immer nur beim ersten Auftreten entsteht,

    VDR schreibt den LOCK-Bericht nur ein mal nach dem Start...


    Mal ganz davon abgesehen: Die Programmübersicht von scraper2vdr verwenden doch bestimmt nur sehr wenige. Bei mir ist z. B. die Programmübersicht von epgsearch aktiv. Bei der bekomme ich keine LOCK-Berichte :/

    Habe den Vorschlag mal eingebaut. Leider kein Erfolg

    Ich werde die Tage noch den Code bei SetTimer... einbauen und weiter testen...

    Zitat von MegaV0lt

    Leider kein Erfolg

    Das stimmt so nicht ganz, den der erste "invalid lock sequence report" ist ja nun weg, und skinflatplus taucht in dem neuen Report nicht mehr auf.


    Der neue Report sagt ja auch nur, das es noch mehr Probleme gibt, und jetzt wird halt das nächste Problem angezeigt...

    Und so wie der aussieht, wäre live jetzt das nächste Plugin, das mal diesbezüglich angesehen werden müsste.


    Ich würde jetzt erst einmal live deaktivieren und schauen, ob es dann ohne neue Reports funktioniert.

    Man muss sich hier Schritt für Schritt vorarbeiten, bis der letzte Report verschwunden ist.


    Grüße

    kamel5

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

    Git-Repo: gitlab.com/kamel5

    OK, danke. Live hab ich eigentlich eh nur zum testen drauf gemacht. Verwende VDRAdmin. Wenn ich wieder Zeit habe, schau ich weiter

    Noch eine Frage: Kann man die LOCKs vom VDR abfragen? Falls ja, könnte man einfach warten bis der entsprechende LOCK wieder frei ist.

    Damit löst du das Problem nicht. Wenn sich jedes Plugin an die vorgegebene Reihenfolge der Locks hält, bekommt du immer einen Lock. Die Fehlermeldung sagt ja auch nicht, dass du keinen Lock bekommen hast (dann würde dein Plugin hängen), sondern dass die Reihenfolge nicht stimmt.

    Zitat von kamel5

    Die richtige Reihenfolge der LOCKs ist 1.Timers, 2. Channels, 3. Recordings, 4. DelRecordings und 5. Shedules.

    Zitat von MegaV0lt

    Kann man die LOCKs vom VDR abfragen?

    Ja. Beispiel: Timer

    Das löst aber, wie kfb77 schon schrieb, Dein Problem in diesem Falle nicht. Das würde nur funktionieren, wenn die LOCKs in nicht voneinander abhängigen Code-Teilen passieren würden.


    Man könnte sich natürlich fragen, warum man das bei 2 Read LOCKs überhaupt beachten sollte, das hat der VDR Entwickler so festgelegt... und Ausschließen, das es dadurch Nebeneffekte geben könnte, kann man auch nicht.


    Grüße

    kamel5

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

    Git-Repo: gitlab.com/kamel5

    Die Meldungen wird man nie ganz weg bekommen. Es kann z.B. sein, dass ein Plugin die Channels lockt und ein anderes danach die Timer. Dann kommt diese Meldung, aber es besteht keine Gefahr eines Deadlocks weil das Plugin mit den Channels die Timer nicht lockt. Wenn es natürlich auch die Timers braucht (inklusive Locks im Core-VDR), muss es die in der richtigen Reihenfolge locken.

    Zitat von FireFly

    Die Meldungen wird man nie ganz weg bekommen. Es kann z.B. sein, dass ein Plugin die Channels lockt und ein anderes danach die Timer. Dann kommt diese Meldung, aber es besteht keine Gefahr eines Deadlocks weil das Plugin mit den Channels die Timer nicht lockt. Wenn es natürlich auch die Timers braucht (inklusive Locks im Core-VDR), muss es die in der richtigen Reihenfolge locken.

    Leuchtet mir jetzt nicht ein.

    "dass ein Plugin die Channels lockt und ein anderes danach die Timer. Dann kommt diese Meldung"

    glaube ich nicht.


    Die Meldung kommt doch nur, wenn ein thread die Reihenfolge nicht einhält -> wir sollten diesen thread finden ...

    Oder gibt es einen thread, den sich mehrere Plugins teilen? Falls ja, dann solllten die Plugins in diesem thread lieber nichts locken. Oder zumindest alle locks freigeben, bevor das nächste Plugin diesen Thread nutzt.


    Also bitte bitte bitte:

    Finde das Plugin, an dem es liegt. Möglichst wenige Plugins nutzen, und dann prüfen, ob der Fehler immer noch auftritt.



    ~ Markus

    Client1: ASUS P5QC, Dual Core 3G, Cine S2, Ext. Board von TBE, Xubuntu 20.04, VDR 2.6x

    Client2: RPI3

    Server: RPI4, Sundtek SkyTV Dual 2x

    "Ich habe mir angewöhnt keine LOCKs in den Set* Funktionen, die direkt vom VDR aufgerufen werden, zu benutzen."


    Kann ich nur noch mal unterstreichen. Das ist ja ein thread, der vdr gehört. Und da kann vdr schon Locks gesetzt haben, bevor du gerufen wirst... Ja, vermutlich könntest Du das prüfen. Was für ein Aufwand. Und wenn die Prüfung zeigt, dass ein Lock gesetzt ist, der Dir verbietet den von Dir gewünschten Lock zu setzten?


    Dann lieber gleich so kodieren, dass an solchen Stellen kein Lock benötigt wird.


    ~ Markus

    Client1: ASUS P5QC, Dual Core 3G, Cine S2, Ext. Board von TBE, Xubuntu 20.04, VDR 2.6x

    Client2: RPI3

    Server: RPI4, Sundtek SkyTV Dual 2x

    Zitat von MarkusE

    Die Meldung kommt doch nur, wenn ein thread die Reihenfolge nicht einhält

    So sehe ich das auch.

    Jedes Plugin ist sein eigener Thread, eine vorgegebene Plugin übergreifende Reihenfolge gibt es nicht und kann es auch nicht geben.

    Die sequence wird hier geprüft. Da wird zuerst der interne Index für den aktuellen Thread ermittelt, dann die Locks für diesen Thread überprüft

    Zitat

    Dann lieber gleich so kodieren, dass an solchen Stellen kein Lock benötigt wird.

    Das würde ich gerne so machen. Habe aber Null Ahnung wie ich das bewerkstelligen kann.


    Die locks für die max

    Kanalanzahl habe ich nun einfach auf feste vier Stellen ersetzt. Danke für den Vorschlag

    Zitat von MarkusE

    "dass ein Plugin die Channels lockt und ein anderes danach die Timer. Dann kommt diese Meldung"

    glaube ich nicht.

    Ist aber damals lt. syslog so gewesen (wobei es auch andere der vier Resourcen gewesen sein können).


    Zitat von MarkusE

    Oder gibt es einen thread, den sich mehrere Plugins teilen? Falls ja, dann solllten die Plugins in diesem thread lieber nichts locken.

    Die Plugins laufen ja erst mal alle innerhalb des Main Thread des VDR.


    Es geht ja darum Deadlocks zu vermeiden, d.h. wenn verschiedene Threads die vier Resourcen in unterschiedlicher Reihenfolge locken kann es dazu kommen. Wenn jetzt ein Plugin nur die Channels braucht sehe ich keinen Grund auch die Timers zu locken. Wenn der andere Thread dann zusätzlich die Channels locken will, muss er halt warten bis der erste die Channels frei gibt. Zum Deadlock kommt es ja erst dann, wenn der Thread, der die Channels gelockt hat noch die Timers locken möchte. Das darf er eben nicht in dieser Reihenfolge.

    VDR protokolliert nur die Reihenfolge der Locks, weshalb er auch solche Konstellationen meldet.

    Empfehlen kann ich da das Buch "Multicore Software" von Gleim und Schüle aus dem dpunkt Verlag.

Jetzt mitmachen!

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

Benutzerkonto erstellen Anmelden