[SkinNopacity] Aktuelle Probleme

  • Vielen Dank schon mal fuer die ganzen Updates. Leider bin ich noch nicht dazu gekommen, das auszuprobieren. Kann auch leider noch laenger dauern. Klingt aber alles schon mal gut.

    - weniger Threads (sind jetzt so weit wie möglich eliminiert)

    Dieser Punkt ist Hauptgrund (und der einzig wichtige), warum ich die light-Version verwende. Die vdr-PLUGINS.html ist da eindeutig:

    Code
    1. Directly accessing the OSD is only allowed from the foreground thread, which
    2. restricts this to a <tt>cOsdObject</tt> returned from the plugin's <tt>MainMenuAction()</tt>
    3. function, or any of the skin classes a plugin might implement.

    Ein Skin-Plugin darf also nicht mit mehreren Threads auf das OSD zugreifen. Wenn es doch funktioniert, dann nur zufällig.


    Wenn die Threads so weit wie moeglich eliminiert sind, welche gibt es noch?

    Möglicherweise liegt das am dvbhddevice Plugin.

    Soweit ich weiss benutzt dvbhddevice die Standard-OSD-Implementierung von vdr (im Gegensatz zu dvbsddevice). Erst das fertig gerenderte OSD wird auf die Hardware uebertragen. Das cPixmap::Lock() hat somit nichts mit der Hardware oder dem Plugin zu tun, denke ich. Wird da auch mit mehreren Threads drauf zugegriffen? Oder passiert bei dem ersten Aufruf irgendeine Initialisierung, die vielleicht auch Hardware-Parameter abfragt?


    Gruss,

    S:oren

  • Leider bin ich noch nicht dazu gekommen, das auszuprobieren. Kann auch leider noch laenger dauern. Klingt aber alles schon mal gut.

    Kein Problem, hat bei mir ja auch etwas länger gedauert.

    Wenn die Threads so weit wie moeglich eliminiert sind, welche gibt es noch?

    Im Moment gibt es noch 3 Threads:

    1. fade-in und fade-out

    2. Scrolling der Menüeinträge

    3. Scrolling des Info-Fensters bei schmalem Menü und Video skaliert


    Der erste ist soweit unabhängig, kann in allen OSD's auftreten und ist nur im kurzen Moment des fade-in bzw. fade-out aktiv.

    Den zweiten und dritten gibt es nur im Hauptmenü bei Listen, wie Aufnahmen, Timern usw. Sie können einzeln und auch zusammen auftreten. Hier ist mir noch keine gute Lösung zum Synchronisieren eingefallen.

    Diese 3 Threads sind für den Skin optional und können im Setup mit "Use animation" abgeschaltet werden.

    Wird da auch mit mehreren Threads drauf zugegriffen? Oder passiert bei dem ersten Aufruf irgendeine Initialisierung, die vielleicht auch Hardware-Parameter abfragt?

    Diese cPixmap::Lock() sind zwar in Threads, aber unabhängig davon tritt dieser Effekt auf. Wenn man z.B. in cNopacityDisplayChannel::Flush so ein cPixmap::Lock() einbaut, entsteht der gleiche Effekt. Und wenn man das cPixmap::Lock() weg läßt, dauert das erste osd->Flush() länger.

    Da das bei z.B. softhddevice nicht auftritt, muss es wohl an der Kette dvbhddevice -> TT6400 liegen. Ob da eventuell schon Hardwareparameter abgefragt werden, kann ich nicht sagen, das dvbhddevice Plugin übersteigt im Moment meine Möglichkeiten.

    Da sich dieser Effekt nur beim ersten Lock/Flush bemerkbar macht, ist das jetzt nicht ganz so schlimm, obwohl das OSD gefühlt durchaus etwas schneller angezeigt werden könnte.


    Grüße

    kamel5

    VDR 2.5.6: ASUS Prime X470-PRO, Ryzen 7 2700, 64GB, 6TB HD, GT1030, Fedora 35 Kernel 5.14 X86_64, Devicebonding 2 x 1 auf 2, TT6400, DVBSky S952 V3

    Git-Repo: gitlab.com/kamel5

  • ich versuche, den devel-branch unter vdr-2.4.7 zu kompilieren und bekomme

    Code
    1. menuitem.c: In member function ‘void cNopacityRecordingMenuItem::DrawRecordingIcons()’:
    2. menuitem.c:1360:38: error: ‘const class cRecordingInfo’ has no member named ‘Errors’
    3. 1360 | if (imgIconErr && Info && (Info->Errors() > 0)) {
    4. | ^~~~~~
    5. make: *** [Makefile:78: menuitem.o] Fehler 1

    unterstützt die devel-branch die aktuelle stable version des vdr nicht mehr?

    ACT-620, Asrock B75 Pro3-M, Intel Core i3-3240, 4 GB DDR3 RAM 1600 MHz, passive Geforce GT1030 von MSI, Sandisk 2TB SSD, 2xWinTV DualHD, Atric-IR-Einschalter. SW: Xubuntu 20.04 auf 64GB Sandisk SSD.

  • Dr. Seltsam ,


    Danke fürs Finden.

    Das sollte schon noch abwärts kompatibel sein. Ich hatte da eine API-Abfrage vergessen.

    Ist im Branch devel jetzt korrigiert. Also bitte noch mal testen.


    Grüße

    kamel5

    VDR 2.5.6: ASUS Prime X470-PRO, Ryzen 7 2700, 64GB, 6TB HD, GT1030, Fedora 35 Kernel 5.14 X86_64, Devicebonding 2 x 1 auf 2, TT6400, DVBSky S952 V3

    Git-Repo: gitlab.com/kamel5

  • kompiliert und läuft. Wenn mir im Langzeitbetrieb irgendwas auffällt, melde ich mich nochmal

    ACT-620, Asrock B75 Pro3-M, Intel Core i3-3240, 4 GB DDR3 RAM 1600 MHz, passive Geforce GT1030 von MSI, Sandisk 2TB SSD, 2xWinTV DualHD, Atric-IR-Einschalter. SW: Xubuntu 20.04 auf 64GB Sandisk SSD.

  • Hallo kamel5,


    ich habe den aktuellen devel-Branch mit vdr-2.5.6 die letzten Tage getestet. Einmal auf einem i.mx6 Quad-Core System mit FFHD6400 und auf einem rpi3b+ mit rpihddevice-Ausgabe-Plugin. Folgendes ist mir dabei aufgefallen…

    Auf beiden Systemen dauert der Aufruf der EPG-Detail-Info sehr lange. Mit der FFHD6400 dauert es grob 2 Sekunden und auf dem rpi3b+ ein bisschen weniger… Allerdings dauert der Aufruf der EPG-Details-Info aus den Aufnahmen nicht so lange, da wird sofort die Info angezeigt…

    Kann man noch etwas an der EPG-Detail-Info etwas optimieren oder habe ich vielleicht im Setup etwas falsch eingestellt? (Kannst du dies vielleicht nachvollziehen?)
    Ansonsten gefällt mir die neue Version mit dem neuem Setup-Aufbau sehr gut.. 👍😁


    Gruß

    Uwe

    The post was edited 1 time, last by Uwe ().

  • Uwe ,

    Allerdings dauert der Aufruf der EPG-Details-Info aus den Aufnahmen nicht so lange, da wird sofort die Info angezeigt…

    Das wundert mich ein wenig, da für Beide im Prinzip der selbe Code verwendet wird.

    Auf beiden Systemen dauert der Aufruf der EPG-Detail-Info sehr lange. Mit der FFHD6400 dauert es grob 2 Sekunden und auf dem rpi3b+ ein bisschen weniger…

    2 Sekunden ist doch sehr lang. Ich nutze hier auch die TT6400 und bei mir unterscheiden sich die Zeiten zwischen EPG-Info und Aufnahmen-Info unerheblich und liegen unter 1 Sekunde.


    Großen Einfluss auf die Zeiten, vor allem beim Menü (dazu gehört auch die Info-Seite), bei der TT6400 hat ein aktives fade-in.

    Du kannst im Setup des Plugins "Animation benutzen" auf "Nein" stellen, dann treten keine diesbezüglichen Effekte auf.


    Wenn Deine Signatur stimmt, nutzt Du auch keine Scraper-Infos. Davon kann es dann auch nicht kommen.

    Was kannst Du noch tun:

    - Probiere mal ein anderes Theme, vielleicht verhält sich das anders.

    - Im Plugin-Setup "Reiter in der Detail Ansicht benutzen" auf "Nein" stellen, dann wird im Moment anderer Code benutzt.


    Wenn das alles nichts bringt, poste bitte mal Deine Plugin-Einstellungen, dann kann ich es hier mal damit testen.


    Zum rpi kann ich im Moment auch nur empfehlen mit den oben genannten Einstellungen zu experimentieren.

    Ich habe hier mittlerweile auch einen rpi3b+ und einen rpi4 und wollte sie mit einem VDR bestücken, das habe ich aus Zeitgründen bisher aber noch nicht geschafft. Ich werde versuchen, das mal in nächster Zeit umzusetzen, möglicherweise ergibt das dann neue Erkenntnisse.


    Grundsätzliches zu den Änderungen im Branch devel bzgl. Info-Ansicht:

    Die einzig wichtige Änderung ist das Deaktivieren der Threads. Das führt gefühlt zu einem etwas langsameren Aufbau der Info-Ansicht. Allerdings werden dadurch alle OSD-Elemente gleichzeitig angezeigt. Das halte ich persönlich für die bessere Lösung (auch bei der TT6400), ist aber grundsätzlich auch Geschmackssache und kann bei langsamer Hardware durchaus etwas länger dauern.


    Grüße

    kamel5

    VDR 2.5.6: ASUS Prime X470-PRO, Ryzen 7 2700, 64GB, 6TB HD, GT1030, Fedora 35 Kernel 5.14 X86_64, Devicebonding 2 x 1 auf 2, TT6400, DVBSky S952 V3

    Git-Repo: gitlab.com/kamel5

  • Die einzig wichtige Änderung ist das Deaktivieren der Threads. Das führt gefühlt zu einem etwas langsameren Aufbau der Info-Ansicht. Allerdings werden dadurch alle OSD-Elemente gleichzeitig angezeigt. Das halte ich persönlich für die bessere Lösung (auch bei der TT6400), ist aber grundsätzlich auch Geschmackssache und kann bei langsamer Hardware durchaus etwas länger dauern.

    Ich bin leider noch nicht dazu gekommen, hier mal draufzuschauen (und werde leider auch sobald keine Zeit haben). Aber wenn es mit den neuen Änderungen langsamer wird als im light-Branch (auch ohne die ganzen Threads), dann stimmt irgendwas nicht. Da muss ich nicht im Sekundenbereich warten (auf der S2-6400).


    Gruss,

    S:oren

  • Hallo S:oren ,

    Da muss ich nicht im Sekundenbereich warten (auf der S2-6400).

    das ist ja das Seltsame. Wahrscheinlich ist das auch noch stark von der restlichen Harware abhängig.


    Ich habe es gerade bei mir nochmal verglichen, Bei mir vergeht bis zum erscheinen des Menüs und dazu gehört auch die EPG-Info/Aufnahme-Info (hier ist nicht die Kanal-Info beim Umschalten eines Senders gemeint), so knapp eine Sec. Und das sowohl bei der aktuellen devel, als auch der light_version. Da unterscheiden sich die Beiden nicht. Anders sollte es auch nicht sein, den ich habe den betreffenden Code quasi 1:1 übernommen.

    Wenn man also in der devel-Version "Scraper...", Animationen..." und "Reiter..." auf "Nein" stellt, sollte es sich genau so wie die light_version verhalten. Zumindest bei mir ist das so.

    (und werde leider auch sobald keine Zeit haben).

    Das ist kein Problem, ich habe im Moment auch nicht so viel Zeit.

    Im Endeffekt lässt sich aber wohl nur auf der gleichen Hardware feststellen, ob sich da ein zeitlicher Unterschied zeigt.


    Ich werde als Nächtes mal ein paar Zeitmessungen in die light_version und die devel Version einbauen und schauen ob sich da ein signifikanter Unterschied ergibt.


    Nachtrag:

    1 Sec vergeht bei mir übrigens auch beim Skin LCARS, wenn ich das Menü aufrufe.


    Grüße

    kamel5

    VDR 2.5.6: ASUS Prime X470-PRO, Ryzen 7 2700, 64GB, 6TB HD, GT1030, Fedora 35 Kernel 5.14 X86_64, Devicebonding 2 x 1 auf 2, TT6400, DVBSky S952 V3

    Git-Repo: gitlab.com/kamel5

  • 1 Sec vergeht bei mir übrigens auch beim Skin LCARS, wenn ich das Menü aufrufe.

    Das klingt doch fast so, als ob die vdr-interne OSD-Implementierung hier beim ersten Aufruf irgendwie recht lange braucht. Ist jetzt nur eine Idee aufgrund vorheriger Posts, ich habe da nichts getestet. Eine Sekunde vergeht bei mir nicht, das wuerde mich wahnsinnig machen. Oder mein Zeitgefuehl ist komplett kaputt.


    Ich habe im dvbhddevice-Plugin OSD Größe 1280x720 und TrueColorFormat ARGB8888 eingestellt, das hat vermutlich Einfluss...


    Gruss,

    S:oren

  • Wahrscheinlich ist das auch noch stark von der restlichen Harware abhängig.

    Ach ja, ich hatte den Spezial-Support fuer steinalte Hardware (z.B. armv5, Cyrix C7) aus dem Treiber entfernt. Aber fuer alles halbwegs aktuelle (armv7+, x86 Core-Whatever, alles 64bittige) sollte es da keinen Engpass geben.


    Gruss,

    S:oren

  • Ich habe im dvbhddevice-Plugin OSD Größe 1280x720 und TrueColorFormat ARGB8888 eingestellt, das hat vermutlich Einfluss...

    Das könnte tatsächlich eine Ursache sein. Ich habe zwar auch ARGB8888, aber OSD-Größe auf "folge Auflösung" stehen und Auflösung auf fest 1080i.

    Ich werde mal testen, ob sich da Unterschiede ergeben.

    Eine Sekunde vergeht bei mir nicht, das wuerde mich wahnsinnig machen.

    Man gewöhnt sich an alles:)

    Und die nachfolgende Bedienung im Menü ist ja schneller...


    Grüße

    kamel5

    VDR 2.5.6: ASUS Prime X470-PRO, Ryzen 7 2700, 64GB, 6TB HD, GT1030, Fedora 35 Kernel 5.14 X86_64, Devicebonding 2 x 1 auf 2, TT6400, DVBSky S952 V3

    Git-Repo: gitlab.com/kamel5

  • Hallo kamel5,


    nach diversen Tests und auch Aktualisierung des Kernel auf 5.13.9 ist das Problem bei mir weiterhin vorhanden.
    Nachdem ich nun einige Plugins deaktiviert hatte, konnte ich das Plugin epgsearch als Übeltäter ausmachen. Das Plugin habe ich von hier.

    Nutzt ihr auch epgsearch, wenn ja, von wo?


    Sorry, dass ich erst skinnopacity im Verdacht hatte… 😉


    Gruß

    Uwe

  • Hallo Uwe ,


    Nachdem ich nun einige Plugins deaktiviert hatte, konnte ich das Plugin epgsearch als Übeltäter ausmachen.

    Das ist ja wirklich seltsam. Ich nutze das Plugin auch, aus der gleichen Quelle.. Bei mir tritt so ein Effekt nicht auf. Mhhh.

    Sorry, dass ich erst skinnopacity im Verdacht hatte… 😉

    Kein Problem. Es hätte ja sein können.


    Grüße

    kamel5

    VDR 2.5.6: ASUS Prime X470-PRO, Ryzen 7 2700, 64GB, 6TB HD, GT1030, Fedora 35 Kernel 5.14 X86_64, Devicebonding 2 x 1 auf 2, TT6400, DVBSky S952 V3

    Git-Repo: gitlab.com/kamel5

  • Aktuell lade ich das epgsearch-Plugin als letztes, habe die epg.data gelöscht, erstelle keine neuen Sender mehr (vorher knapp 2000 Kanäle in der channels.conf) jetzt knapp 50 Kanäle und aktualisiere nur die Namen und PIDs der Kanäle…

    Damit habe ich diesen Effekt aktuell nicht mehr… mhhh, alles seltsam… 😉

    The post was edited 1 time, last by Uwe ().

  • Ich habe in der commands.conf den Eintrag

    Code
    1. Syslog anzeigen : tail -n 100 /var/log/syslog

    Wenn ich den mit dem aktuellen nopacity-skin (devel) aufrufe, legt vdr einen Neustart hin. Im syslog sieht man nichts relevantes:


    Code
    1. Aug 13 00:28:50 ubuntuvdr2 vdr: [31734] executing command 'tail -n 100 /var/log/syslog'
    2. Aug 13 00:28:50 ubuntuvdr2 lircd[803]: lircd-0.10.1[803]: read_timeout: read() failed: Connection reset by peer
    3. Aug 13 00:28:50 ubuntuvdr2 lircd[803]: lircd-0.10.1[803]: Info: removed client
    4. Aug 13 00:28:50 ubuntuvdr2 lircd-0.10.1[803]: read_timeout: read() failed: Connection reset by peer
    5. Aug 13 00:28:50 ubuntuvdr2 lircd-0.10.1[803]: Info: removed client
    6. Aug 13 00:29:00 ubuntuvdr2 vdr: [32231] VDR version 2.4.6 started


    Wenn ich vdr zuvor in der Konsole gestartet habe, wird

    Code
    1. Magick: abort due to signal 11 (SIGSEGV) "Segmentation Fault"...


    geloggt.


    Mit einem anderen Skin sowie der master-branch von nopacity passiert das nicht!


    Dies ist meine Konfiguration:


    Das Makefile ist Standard:

    Code
    1. # External image lib to use: imagemagick, graphicsmagick
    2. #IMAGELIB = imagemagick
    3. IMAGELIB = graphicsmagick

    ACT-620, Asrock B75 Pro3-M, Intel Core i3-3240, 4 GB DDR3 RAM 1600 MHz, passive Geforce GT1030 von MSI, Sandisk 2TB SSD, 2xWinTV DualHD, Atric-IR-Einschalter. SW: Xubuntu 20.04 auf 64GB Sandisk SSD.

  • Moin,


    zu dem "1 s beim ersten OSD Aufruf" Problem: ich erinnere mich dunkel, dass einige DVB Karten bzw. die Treiber sehr lange benötigen, bis die Signalinformationen der DVB Adapter gelesen sind. Deshalb tritt dieser Effekt bei manchen auf, bei manchen nicht...


    Ciao Louis

  • Wenn ich den mit dem aktuellen nopacity-skin (devel) aufrufe, legt vdr einen Neustart hin.

    Kann ich hier nachvollziehen, schaue ich mir an.

    zu dem "1 s beim ersten OSD Aufruf" Problem: ich erinnere mich dunkel, dass einige DVB Karten bzw. die Treiber sehr lange benötigen, bis die Signalinformationen der DVB Adapter gelesen sind. Deshalb tritt dieser Effekt bei manchen auf, bei manchen nicht...

    Das ist mir auch schon aufgefallen.

    Das koennte erklaeren, warum ich bei OSD Größe 1280x720 im dvbhddevice-Plugin so einen Effekt nicht sehe. Bei fester OSD-Aufloesung muss nicht auf ein Signal gewartet werden.

    Das Problem ist hier allerdings, das dieser Effekt bei mir nur in Verbindung mit der TT6400 auftritt. Wenn ich z.B. Softhddevice als Ausgabeplugin benutze, tritt dieser Effekt nicht auf. Und dieser Effekt tritt z.B. auch bei OSD's auf, die keine Signalabfrage durchführen.

    Ich muss bei Gelegenheit mal schauen, ob ich das noch eingrenzen kann.


    Grüße

    kamel5

    VDR 2.5.6: ASUS Prime X470-PRO, Ryzen 7 2700, 64GB, 6TB HD, GT1030, Fedora 35 Kernel 5.14 X86_64, Devicebonding 2 x 1 auf 2, TT6400, DVBSky S952 V3

    Git-Repo: gitlab.com/kamel5