[Announce] vdr-plugin-tvscraper 1.2

  • Skindesigner scheint beim Scrollen durch diese Listen haufenweise Threads zu starten, was zu Problemen führt ...

    Ich habe mal kurz darüber nachgedacht. Das mit den vielen Threads ist normales Verhalten.

    Der Ablauf ist folgender:

    Wenn man z.B. im Programmmenü ist, wird ja für den aktuellen Menüeintrag etwas, in dem Falle ein Thread, ausgelöst, z.B. die Infoanzeige rechts (mit Ein- und Ausblenden und Scrollen, wenn das vom Skin so vorgegeben wird). Wenn man jetzt zu dem nächsten Menüeintrag geht, wird der aktuelle Thread beendet, was unter Umstäden zu einem "canceling it..." führt, wenn das nicht schnell genug geht, wobei 2s Wartezeit schon recht lang ist. Man könnte diese Wartezeit noch etwas erhöhen und schauen, ob es dann nicht so viele canceling gibt.

    Man sieht in dem Log auch, das sich die Threads überlappen, was eigentlich auch kein Problem sein sollte.


    Ich denke also nicht, das das an den Threads liegt, ich wüste im Moment auch nicht, wie man das ohne größeren Aufwand umbauen sollte.

    Vielleicht liegt die Ursache auch ganz woanders...


    Grüße

    kamel5

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

    Git-Repo: gitlab.com/kamel5

  • Mit dem Unterschied das jetzt der Ton im Hintergrund weiterläuft und es keinen Neustart mehr gibt.

    Könntest Du versuchen, in so einem Fall mal einen coredump zu erstellen. Es müsste ja, wenn der VDR hängen bleibt, der Watchdog zuschlagen. Sonst wird es schwierig, genau die Stelle zu finden, wo es stehen bleibt.


    Grüße

    kamel5

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

    Git-Repo: gitlab.com/kamel5

  • Hi,


    Anbei ein Patch gegen vdr-plugin-skindesigner, der die Wartezeit auf 20s hochsetzt. Damit konnte ich den Fehler nicht mehr reproduzieren. Taipan , kannst Du das bitte testen?


    Viele glechzeitige Threads auf langsamen Systemen (rpi3), da kann es schon mal passieren, dass einer länger dauert.

    Ich denke, dass diese Threads Resourcen am UI belegen (OSD, Pixmaps, ... bin da nicht so tief drin), die nicht mehr freigegeben werden, wenn VDR den Thread canceled.


    ~Markus

  • Der VDR beendet sich nach wie vor nicht mehr aber die langen 'Hänger' bleiben und machen die Sache hier auf dem Produktivsystem für uns nicht nutzbar. Bin jetzt zurück auf die lokale Variante.

  • Anbei ein Patch gegen vdr-plugin-skindesigner, der die Wartezeit auf 20s hochsetzt.

    Soll ich die Wartezeiterhöhung erst einmal übernehmen, auch wenn mir auf 20s etwas viel erscheint, aber schaden kann es eigentlich auch nicht.


    Grüße

    kamel5

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

    Git-Repo: gitlab.com/kamel5

  • Ich habe mir auch das tvscraper Handling im skindesigner nochmal angesehen. Das wird in "extensions/scrapmanager.c" realisiert und ist überschaubar. Auf den ersten Blick ist da alles abgefangen, was geht.

    Die einzige Schwachstelle sehe ich für den Fall, das tvscraper nicht antwortet, dann kann der skindesigner nichts machen, außer warten, und das würde dann zu dem beobachteten Verhalten führen.

    Hier könnte man auch leicht debug-Meldungen einbauen, um zu sehen, wo es genau passiert.


    Der segfault von oben im detacher-thread ist aus meiner Sicht nicht die Ursache, sondern nur das Ergebnis, wenn dann nach einem Timeout der VDR vom watchdog abgeschossen wird.


    Grüße

    kamel5

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

    Git-Repo: gitlab.com/kamel5

  • Inzwischen gibt es keinen Segfault mehr in tvscraper, dieser Fehler ist behoben.


    > Die einzige Schwachstelle sehe ich für den Fall, das tvscraper nicht antwortet

    Passiert nicht, tvscraper antwortet immer.

    Was länger dauert, ist das Malen des UI.


    Die Frage ist, welche UI Ressourcen der Thread beansprucht/reserviert, und nicht mehr freigibt wenn er von VDR hart beendet wird.


    > Soll ich die Wartezeiterhöhung erst einmal übernehmen, auch wenn mir auf 20s etwas viel erscheint

    Ja bitte.

    Ist die einfachste Lösung, mit der verhindert wird, dass diese Threads hart beendet werden. Wie gesagt, ein hartes Beenden führt zu dauerhaft blockierten UI Ressourcen und damit dazu, dass der VDR das UI nicht mehr darstellen kann.


    ~ 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

  • Sorry,

    ich versuche das nochmal zu erläutern.

    Wenn ich beispielsweise in der Primetime ssuchen will und im EPG runtergehe (down) geht es ein, zwei, dreimal sauber aber dann kommt ein Hänger. Das Bild und die Info (shady_KISS rechtes Fenster) folgen verzögert um Sekunden.

    Scrolle ich schnell (gedrückte Taste down) und halte an ist es so wie vorher, nur das das OSD genauso unbedienbar stehenbleibt (hängt) und dann war es das bis zum Neustart per ssh.

    Innerhalb von skinnopacity kann ich hoch- runterscrollen wie ich will - die Infos kommen sofort (max. halbe Sekunde)


    Was mich stutzig macht, das ich entweder der einzige bin der das Plugin im Client/Serverbetrieb testet - oder bei dem es nicht lööft !? ?(

  • > aber die langen 'Hänger' bleiben

    Taipan , was genau meinst Du damit? Längere Wartezeit, Absturz des VDR, ...?


    OK, veraltert, taipan hat es schon beantwortet

    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

  • Taipan , mit dem aktuellen tvscraper git und meinem Patch gegen skindesigner läuft es bei mir stabil im Client/Server Betrieb.


    Stelle doch mal den Log Level von VDR hoch, so dass Du die Meldungen


    Quote

    Aug 11 22:24:50 rpi3 vdr: [4295] epg data writer thread started (pid=413, tid=4295, prio=low)

    Aug 11 22:24:51 rpi3 vdr: [4295] epg data writer thread ended (pid=413, tid=4295)


    im Syslog siehst.


    ~ 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

  • Quote

    Was mich stutzig macht, das ich entweder der einzige bin der das Plugin im Client/Serverbetrieb testet - oder bei dem es nicht lööft !? ?(

    Ich benutze ebenfalls den Server/Clientbetrieb vom tvscraper und den skindesigner. Die Hänger beim durchscrollen habe ich auch, aber max eine Sekunde !

    Als ich mal Probleme mit der Netzwerkverbindung hatte (nur 100 MB/sec) hatte ich ebenfalls Hänger > 2 Sekunden und dadurch einen Absturz bei VDR.

    Warum diese Hänger nur im Skindesigner auftreten weiß ich nicht. Mein Client VDR ist allerdings sehr leistungstungsstark (I5 mit 3 GHz +16 GB RAM). Das macht sich beim Skindesigner positiv bemerkbar. ;)


    Übrigens komischerweise ist bei Primetime Filmen der Bildaufbau während des scrollens im EPG auch bei mir länger.


    Habe gerade nochmal einen Test der Geschwindigkeit beim scrollen gemacht und dabei festgestellt, dass nur wenn mehrere Schauspieler in der tvscraper Datenbank abgefragt werden, die Anzeige etwas länger hängt. Das ist aber nur bei Movies der Fall, nicht bei Serien !

  • Habe gerade nochmal einen Test der Geschwindigkeit beim scrollen gemacht und dabei festgestellt, dass nur wenn mehrere Schauspieler in der tvscraper Datenbank abgefragt werden, die Anzeige etwas länger hängt.

    OK, das es etwas länger dauert, wenn mehr Schauspieler vorhanden sind, ist schon möglich. Das Problem könnte hier sein, das beim Scrollen im Menü die Schauspieler abgefragt werden, obwohl das eigentlich nicht nötig ist. skinnopacity macht das auf jeden Fall nicht so.

    Ich muss mal schauen, wie da genau die Verhältnisse sind, und ob man da noch etwas verbessern kann.

    Das könnte allerdings etwas dauern.


    Grüße

    kamel5

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

    Git-Repo: gitlab.com/kamel5

  • Ich muss mal schauen, wie da genau die Verhältnisse sind, und ob man da noch etwas verbessern kann.

    Ich habe jetzt doch mal schnell geschaut, es werden im Menü keine Schauspieler geladen. Das ist schon mal gut.


    Grundsatzlich muss man beim skindesigner folgendes festhalten:

    Durch die Möglichkeit über eine xml-Datei einen Skin zu kreieren, kann es niemals so schnell funktionieren, wie bei einem nativen Skin. Durch die Komplexität gibt es erheblichen Verwaltungsaufwand, schließlich werden hier viele Tokens befüllt, auch die, die nicht benutzt werden. Ein schneller Rechner ist hier sicher von Vorteil. Ich habe hier z.B. noch nie Probleme mit der Geschwindigkeit beim Laden von TVScraper-Daten gehabt. Auch beim Laden von Schauspielerfotos, auch bei größerer Anzahl, gab es keine sichtbare Verzögerung. Ich nutze hier eine lokale Installation von TVScraper.

    Wenn es also mit einer lokalen Installation problemlos läuft, und bei einer Client/Server Installation nicht, muss man wahrscheinlich doch davon ausgehen, das an diesem Zusammenspiel irgend etwas Probleme macht, es gibt da ja auch nochmal erheblichen Overhead. Auch wenn es z.B. mit skinnopacity problemlos zu gehen scheint.

    Ich wüsste im Moment auch nicht, wie ich darauf Einfluss nehmen sollte, den für den skindesigner ist es ja unerheblich, woher die Daten kommen.


    Grüße

    kamel5

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

    Git-Repo: gitlab.com/kamel5

  • > es werden im Menü keine Schauspieler geladen. Das ist schon mal gut

    Aber es wird doch LoadFullScrapInfo aufgerufen, wenn ich im EPG von einem Eintrag zum Nächsten nach unten gehe (?).

    LoadFullScrapInfo lädt auch die Schauspiler, und einfach alles.

    GetPosterBannerV2 ist da deutlich schneller

    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

  • Aber es wird doch LoadFullScrapInfo aufgerufen,

    Ja, das lädt aber noch nicht die Schauspieler, oder doch. Ich dachte das wird erst in SetFullScrapInfo geladen.

    Oder wird das schon über

    Code
        if (getType.type == tMovie) {
            movie = new cMovie();
            movie->movieId = getType.movieId; 
            pScraper->Service("GetMovie", movie);
            return true;
        }

    geladen. Und die Bilder werden doch auch nur als Verweis aufs Dateisystem geladen, und erst später dann benutzt.

    Oder habe ich da was falsch verstanden.


    Grüße

    kamel5

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

    Git-Repo: gitlab.com/kamel5

  • GetPosterBannerV2 ist da deutlich schneller

    Ist das wirklich soviel, wenn da keine Bilddaten übertragen werden?

    Und bei Serien geht es angeblich schneller, nur wegen evtl. weniger Schauspieler. Mhh.


    Wenn das wirklich so ist, könnte man das sicher auf GetPosterBannerV2 umstellen, das würde aber z.B. nicht in der Detailansicht bei vielen Schauspielern helfen.


    Grüße

    kamel5

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

    Git-Repo: gitlab.com/kamel5

  • Ich glaube, ich habe da, bzgl. des Menüs, etwas gefunden. Es sieht so aus, als ob da etwas doppelt aufgerufen wird. Ich werde mir das morgen mal genauer ansehen.


    Grüße

    kamel5

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

    Git-Repo: gitlab.com/kamel5

  • > Ist das wirklich soviel, wenn da keine Bilddaten übertragen werden?

    Ja.


    Anbei ein Patch für skindesigner. Damit wird das Scrollen durch die Listen (epg, Kanäle, Timer) deutlich schneller.

    Bei allen langsamen Clients sichtbar.


    ~Markus

  • Quote

    Anbei ein Patch für skindesigner. Damit wird das Scrollen durch die Listen (epg, Kanäle, Timer) deutlich schneller.

    Bei allen langsamen Clients sichtbar.

    Ein erster Test sieht gut aus!! Das scrollen ist deutlich besser geworden.

    Thank's

Participate now!

Don’t have an account yet? Register yourself now and be a part of our community!