skindesigner - bad locking order for vdr-2.3.x

  • Tokens {currentrecording}, {nextrecording}, {isRecording} and {devices[recording]} in displaychannel will not work anymore.

    This is not true.

  • Ich hatte mit SkinFlatPlus auch den einen oder anderen Deadlock. Das Problem war da das gleiche, dass die aktiven Timer irgendwo in SetChannel abgerufen wurden. Ich habe das Timer-Holen dann einfach in einem seperaten Thread ausgelagert.


    Für Skindesigner würde das dann so ausssehen (Achtung, das ist ein völlig ungetesteter Patch, der nur zeigt, wie ich das ungefair bei SkinFlatPlus gemacht habe)


    locking-fix.diff

  • Hey louis,

    ich würde mich auch sehr freuen wenn du wieder am vdr weiter arbeiten würdest.

    Habe Deine Arbeit immer sehr wertgeschätzt.

    Gruß

    Geht mir ähnlich, hast auch immer zügig und freundlich auf sämtliche Anregungen und Probleme hinsichtlich deiner Plugins reagiert. Ich fand deinen Support und den Umgang im Forum immer sehr vorbildlich.


    Vielleicht findest du den Weg ja mal wieder zurück.


    Gruss


    Stefan

    Server: VDR 2.4.1 mit Ubuntu 19.04 x64 mit vaapidevice, Kernel 5.2.9, ASRock J4105M, 2 x 4096 MB DDR4-RAM, 2 x DD Cine S2, Lirc-Serial mit One4All URC 7960
    Client: VDR 2.4.1 mit Ubuntu 19.04 x64 mit softhddevice-OpenGL oder mit KODI+vnsiserver, Kernel 5.2.5, ASRock H81M, Intel i3-4150, NVIDIA GPU GeForce GT 610 (GF119), 2 x 2048 MB DDR2-RAM, 1 x Technotrend S2-1600, SilverStone Milo ML03, ASRock Smart Remote CIR mit Logitech Harmony 650, Beamer 120'' FullHD-3D

  • Ich glaube, es gibt viel viel mehr Skindesigner-Nutzer, als hier mit "positiven Beiträgen" auffallen.

    Mich würds auch sehr freuen, wenn du weitermachen würdest; respektiere aber deine Entscheidung.

    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

  • :tup

    Gruß
    Frodo

  • Kann mich da nur anschließen. Ohne Skindesigner ist vdr optisch so ziemlich 90er-mässig.

    Erst mit skindesigner wird daraus was anständiges.

    Ich würde es auch begrüßen wenn das Plugin wenigstens funktionstüchtig gehalten wird.

    Louis seine Hilfe hier war auch immer sehr anständig!

  • Ohne Skindesigner ist vdr optisch so ziemlich 90er-mässig.

    Erst mit skindesigner wird daraus was anständiges.

    Kommt halt immer darauf an, wozu man es benutzt ;-).

    Als Video-Spiel ist es echt etwas eintönig, da hast du recht. Ich nehme es daher eigentlich nur zum Aufnehmen und Wiedergeben von TV-Sendungen her ;-).


    Klaus

  • @Klaus

    Das ist das Problem vom VDR und weshalb das Programm auch sein Leben als Backend für Kodi fristet.. weil der Hauptentwickler ja mit seiner 90er-Jahre-Optik zufrieden ist und auch mit Einschränkungen wie kein GIT und bloß keine großen Veränderungen.. aber das steht ja im Forum schon zur genüge..

  • was prinzipiell mit der GUI möglich ist sieht man ja im demo plugin / da ginge schon einiges ....

  • Volle Zustimmung :thumbup:

  • Ich hatte mit SkinFlatPlus auch den einen oder anderen Deadlock. Das Problem war da das gleiche, dass die aktiven Timer irgendwo in SetChannel abgerufen wurden. Ich habe das Timer-Holen dann einfach in einem seperaten Thread ausgelagert.


    Für Skindesigner würde das dann so ausssehen (Achtung, das ist ein völlig ungetesteter Patch, der nur zeigt, wie ich das ungefair bei SkinFlatPlus gemacht habe)


    locking-fix.diff


    Da die Holzhammer Variante bei mir gut läuft, habe ich deine Lösung jetzt nicht mehr getestet. Trotzdem danke für den konstruktiven Beitrag!

  • Here we go again, but this time epg2vdr and his timer service is involved, too :(

    I doesn't see this kind of errors on my main vdr, only on the raspberries ...


    And some minutes later I got this:

    Sad but true, skindesigner isn't usable with my raspberry anymore.

  • Exakt denselben Fehler hab ich hier auch (noch mit vdr-2.3.8)

    Der Backtrace ist ein bisschen detaillierter:

    Wenn ich nun analog zum Patch von nanohvc diesen patch anwende:


    bekomme ich diesen Compile error:

    Code
    displayreplay.c: In lambda function:
    displayreplay.c:98:30: error: 'globalTimers' is not captured
             std::async([this](){ globalTimers.LoadTimers(); }).get();
                                  ^~~~~~~~~~~~
    displayreplay.c:98:25: note: the lambda has no capture-default
             std::async([this](){ globalTimers.LoadTimers(); }).get();
                             ^
    displayreplay.c:96:23: note: 'cGlobalTimers globalTimers' declared here

    Hat dazu jemand nen Tipp ?

  • Damit geht es leider ach nicht:


    Code
    displayreplay.c: In member function ‘void cSDDisplayReplay::SetTimeShiftValues(const cRecording*)’:
    displayreplay.c:97:7: error: ‘async’ is not a member of ‘std’
      std::async([&globalTimers](){ globalTimers.LoadTimers(); }).get();
           ^~~~~
    displayreplay.c:97:7: note: suggested alternative: ‘asinh’
      std::async([&globalTimers](){ globalTimers.LoadTimers(); }).get();
           ^~~~~
           asinh
    Makefile:141: recept voor doel 'displayreplay.o' is mislukt
  • Welche gcc-Version verwendest du?

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

Jetzt mitmachen!

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