[skinnopacity] invalid lock sequence report ... mit vdr-2.4.0 und skinnopacity(gepatcht)

  • Trotzdem bleibt die interessante Frage, warum ich keine Fehler bekomme.

    Bei dir ist alles ein wenig anders, haben wir schon kürzlich festgestellt ;)

    Gruß utiltiy



    VDR Projekte VDR Projects

  • Bei dir ist alles ein wenig anders, haben wir schon kürzlich festgestellt ;)

    Hrmpf :)


    Aber mal Spass beiseite: Vor dem letzten Patch hatte ich ebenfalls die Fehler bzgl. "invalid lock sequence", danach waren sie weg - was generell auch Sinn macht, da dieser Patch ja genau an den Stellen dreht, an denen das Locking passiert. Ich hoffe, ich habe wirklich die Sourcen erwischt, die den Patch enthalten.

    Ich schau mir das heute nochmal an.

  • Tja, da kann ich schauen, solange ich will - ich finde keine Unterschiede 8-(

    Allerdings *muss* eigentlich auch bei mir dieser Fehler auftreten.

    Mittlerweile habe ich gefunden, woher der kommt, bin aber leider nicht in der Lage ihn zu beheben.

    Dazu müsste man ziemlich viel umbauen.

    Wenn ich Klaus richtig verstanden habe, ist der Grund, dass an der Stelle in displaymenu.c, an der das passiert, für den 2.3.x Patch ein LOCK_TIMERS_READ eingebaut wurde, dass an dieser Stelle aber bereits ein LOCK_CHANNELS_READ aktiv ist. Dummerweise muss der LOCK_TIMERS_READ *vor* dem LOCK_CHANNELS_READ gemacht werden. Das Plugin hat an dieser Stelle überhaupt keine Chance mehr, das Locking "richtig" zu machen. Klaus hat vorgeschlagen, das in die flush() Methode auzulagern, wenn ein Plugin irgendwelche Timer-Anzeigen machen will. Allerdings ist das deutlich über meinem aktuellen Kenntnisstand zum VDR-Klassenmodell.


    Evtl. hat da jemand Anderes mehr Wissen als ich.


    Siehe auch


    Ciao.

    Michael.

  • Übrigens hat sich die Funktion cEvent::HasTimer() geändert: Früher war sie nur bei aktivem Timer true, jetzt ist sie auch true wenn ein inaktiver Timer existiert. Damit stimmt die Rec-Anzeige des Following Event nicht mehr wenn der Timer inaktiv ist (siehe Listing oben in Post #2 Zeile 24), Aber das ist vermutlich bei so ziemlich allen Skin-Plugins so, die nicht beim VDR mitgeliefert werden, da alle fast den gleichen Code benutzen ;)

    Ich dachte nämlich man könnte das für den Present-Event genauso machen wie für den Following-Event, aber statt einem Workaround gibt's jetzt zwei Probleme ...

  • Mit beigefügtem Patch und dem von Klaus angekündigten Patch bezüglich Flush sollten die oben genannten "invalid lock sequence report" behoben sein.

    Ausserdem wird mit Patch das "Rec"-Symbol bei den Events nur noch angezeigt, wenn ein Timer aktiv ist.


    Dieser Patch ist zusätzlich zu den Anderen anzuwenden.

  • Mit diesem Patch (skinnopacity-timer.diff) baut er nicht unter Arch, habe die Patches drin:

    - vdr_2.3.3_compat.patch

    - skinnopacity_vdr-2.3.5_compat.patch

    - skinnopacity_vdr-2.3.8_compat.patch

    Gruß utiltiy



    VDR Projekte VDR Projects

  • Mit diesem Patch (skinnopacity-timer.diff) baut er nicht unter Arch,

    Was wäre denn die Fehlermeldung?


    OK, das mit den Patches ist wohl etwas unübersichtlich, hier also nochmal ein Gesamtpatch bezogen auf den letzten Stand von hier:

    https://projects.vdr-developer.org/git/skin-nopacity.git/

  • Der läuft durch, Danke :)


    Das war der Fehler,zuvor:

    Gruß utiltiy



    VDR Projekte VDR Projects

  • Ich habe die Anzeige des "Rec"-Symbols am Event noch etwas optimiert. Das Symbol sollte ja eigentlich nur angezeigt werden, wenn der Timer zum Event gehört und nicht wenn der folgende Event in die Nachlaufzeit eines Timers fällt.


    Den beigefügten Patch bitte zusätzlich zu den Anderen anwenden.


    Gruss

    kamel5

  • Ich habe die Anzeige des "Rec"-Symbols am Event noch etwas optimiert. Das Symbol sollte ja eigentlich nur angezeigt werden, wenn der Timer zum Event gehört und nicht wenn der folgende Event in die Nachlaufzeit eines Timers fällt.


    Den beigefügten Patch bitte zusätzlich zu den Anderen anwenden.

    Hallo zusammen,


    ich habe es nun mal geschafft den Patch aus Post 27 und 29 anzuwenden (Danke dafür), bekomme aber im noch den Fehler, wie im Ausgangspost.

    Fehlt jetzt noch der Patch von Klaus (den es vielleicht noch nicht gibt) oder habe ich etwas übersehen?


    Gruß Uwe

  • Dank Dir für die Info, hatte ich übersehen....

    Ich bekomme mit all diesen Patches nun folgenden Backtrace im Log:

    Bekommt das noch jemand?

  • Bekommt das noch jemand?

    Genau dieser "invalid lock sequence report" sollte mit dem letzten Patch von Klaus Geschichte sein.

    Also, nochmal prüfen, ob alles richtig gepatcht, übersetzt und neu installiert wurde.

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

    Git-Repo: gitlab.com/kamel5

  • Ja, ist alles und komplett gepatcht. Da stimmt noch etwas nicht....

  • Danke für deine Mühe!

    Nachdem ich jetzt wieder aus dem Urlaub zurück bin, habe ich die Patches von dir und Klaus entsprechend angewandt und keine Probleme damit - auch alle Fehlermeldungen sind weg (die eben auch bei mir doch da waren - aber ich war irgendwie blind, bzw. urlaubsreif).


    Nur für den Fall - hier die Reihenfolge:


    Code
    - Auspacken vdr-2.4.0 und ins Verzeichnis wechseln
    - patch -p0 <vdr-2.4.0-01-fix-svdrp-modt-recflag.diff
    - patch -p0 <vdr-2.4.0-02-fix-invalid-locking-sequence.diff
    - patch -p0 <vdr-2.4.0-03-fix-locking-channel-display.diff
    - Auspacken aller Plugins nach PLUGINS/src
    - ins Verzeichnis von skinnopacity wechseln
    - patch -p1 <skinnopacity-locking.diff
    - patch -p1 <skinnopacity-channelview-recicon.diff


    Ciao.

    Michael.

  • Also hier kommt es noch zu einem Backtrace.

    Allerdings kommt es zu diesen Fehler sehr viel später. Die Fehlermeldung ist auch eine andere, als wie im Post1. Es scheint also noch ein weiteres Problem zu sein. Der VDR unten wurde 18:30Uhr gestartet, der Backtrace trat 19:23 auf....


    Gruß Uwe


    Edit: falls es eine Rolle spielt, der Fehler auf einem Matrix-ARM Board mit i.mx6 Quad Core.

    Einmal editiert, zuletzt von Uwe ()

  • Nur für den Fall - hier die Reihenfolge:

    Ja, so war es gedacht.

    Die Fehlermeldung ist auch eine andere, als wie im Post1


    Ja, das ist die erwartete Fehlermeldung ohne den Patch von Klaus.

    Was mich wundert ist:

    May 22 19:23:31 matrix-vdr vdr: [456] /usr/bin/vdr cDisplayChannel::ProcessKey(eKeys) at menu.c:4902

    Das sollte eigentlich Zeile 4901 sein...


    Die Funktion an der gepatchten Stelle muss so aussehen:


    Bitte nochmal prüfen, sonst habe ich da auch keine Idee mehr dazu.


    Gruss

    kamel5

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

    Git-Repo: gitlab.com/kamel5

    Einmal editiert, zuletzt von kamel5 ()

  • Hallo,


    gepatcht ist VDR mit allen 3 x Patches von Klaus, das Plugin skinnopacity ist auch mit den beiden vorgesehenen Patches gepatched.

    ...cDisplayChannel::ProcessKey(eKeys) at menu.c:4902 ist bei Dir im Code die Zeile 30.

    Ich denke da stimmt noch etwas nicht. Nur schade das dies keiner bestätigen kann. :)


    Gruß

    Uwe

  • Leider kann ich dir das so nicht bestätigen, da bei mir aufgrund u.a. des graqphtftng Patches die Zeilennummer für

    Code
    eOSState cDisplayChannel::ProcessKey(eKeys Key)

    bei 4745 liegt (kommt auch nur einmal in menu.c vor) 8-<

    Aber dein Fehler tritt hier in keiner Weise oder Zeile auf.


    Ciao.

    Michael.

  • ...cDisplayChannel::ProcessKey(eKeys) at menu.c:4902 ist bei Dir im Code die Zeile 30.

    Zeile 4902 entspricht Zeile 30. Das wäre soweit OK.

    Wenn Du aber in Deiner Meldung das folgende anschaust:

    May 22 19:23:31 matrix-vdr vdr: [456] /usr/lib/vdr/plugins/libvdr-skinnopacity.so.2.4.0 cNopacityDisplayChannel::Flush() at displaychannel.c:140
    May 22 19:23:31 matrix-vdr vdr: [456] /usr/bin/vdr cDisplayChannel::ProcessKey(eKeys) at menu.c:4902

    bedeutet das, das cNopacityDisplayChannel::Flush() in menu.c:4902 aufgerufen wird, und das kann eigentlich nicht sein, denn das displayChannel->Flush() in menu.c steht in Zeile 4901. Da passt irgendwie was nicht zusammen.

    Ich habe mal die gepatchte menu.c hier angehängt, Du kannst mal vergleichen, ob Deine damit identisch ist.


    Gruss

    kamel5

Jetzt mitmachen!

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