[SkinNopacity] Aktuelle Probleme

S:oren · 31. Juli 2021

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.

Zitat von kamel5

- 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

Directly accessing the OSD is only allowed from the foreground thread, which
restricts this to a <tt>cOsdObject</tt> returned from the plugin's <tt>MainMenuAction()</tt>
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?

Zitat von kamel5

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

kamel5 · 31. Juli 2021

Zitat von 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.

Zitat von S:oren

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.

Zitat von S:oren

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

Dr. Seltsam · 7. August 2021

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

Code

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

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

kamel5 · 8. August 2021

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

Dr. Seltsam · 8. August 2021

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

Uwe · 11. August 2021

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

kamel5 · 11. August 2021

Uwe,

Zitat von 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.

Zitat von Uwe

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

S:oren · 11. August 2021

Zitat von 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

kamel5 · 11. August 2021

Hallo S:oren,

Zitat von 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.

Zitat von S:oren

(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

S:oren · 11. August 2021

Zitat von 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

S:oren · 11. August 2021

Zitat von kamel5

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

kamel5 · 11. August 2021

Zitat von 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.

Zitat von S:oren

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

Uwe · 12. August 2021

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

kamel5 · 12. August 2021

Hallo Uwe,

Zitat von 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.

Zitat von Uwe

Sorry, dass ich erst skinnopacity im Verdacht hatte… 😉

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

Grüße

kamel5

Uwe · 12. August 2021

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… 😉

Dr. Seltsam · 13. August 2021

Ich habe in der commands.conf den Eintrag

Code

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

Aug 13 00:28:50 ubuntuvdr2 vdr: [31734] executing command 'tail -n 100 /var/log/syslog'
Aug 13 00:28:50 ubuntuvdr2 lircd[803]: lircd-0.10.1[803]: read_timeout: read() failed: Connection reset by peer
Aug 13 00:28:50 ubuntuvdr2 lircd[803]: lircd-0.10.1[803]: Info: removed client
Aug 13 00:28:50 ubuntuvdr2 lircd-0.10.1[803]: read_timeout: read() failed: Connection reset by peer
Aug 13 00:28:50 ubuntuvdr2 lircd-0.10.1[803]: Info: removed client
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

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:

Code

skinnopacity.darkblue.animation = 0
skinnopacity.darkblue.backgroundStyle = 1
skinnopacity.darkblue.channelFadeTime = 0
skinnopacity.darkblue.debugImageLoading = 1
skinnopacity.darkblue.fontMenuitemDefault = 1
skinnopacity.darkblue.fontMenuitemScheduleSmall = 0
skinnopacity.darkblue.footerHeight = 7
skinnopacity.darkblue.headerHeight = 7
skinnopacity.darkblue.menuChannelDisplayMode = 0
skinnopacity.darkblue.menuEPGWindowFadeTime = 1
skinnopacity.darkblue.menuInfoScrollDelay = 1
skinnopacity.darkblue.menuInfoTextDelay = 2
skinnopacity.darkblue.menuScrollDelay = 1
skinnopacity.darkblue.menuScrollSpeed = 2
skinnopacity.darkblue.menuWidthChannels = 40
skinnopacity.darkblue.menuWidthRecordings = 50
skinnopacity.darkblue.menuWidthSchedules = 50
skinnopacity.darkblue.messageFadeTime = 0
skinnopacity.darkblue.narrowChannelMenu = 1
skinnopacity.darkblue.narrowScheduleMenu = 1
skinnopacity.darkblue.numDefaultMenuItems = 16
skinnopacity.darkblue.numMainMenuItems = 10
skinnopacity.darkblue.numRecordingsMenuItems = 8
skinnopacity.darkblue.numSchedulesMenuItems = 7
skinnopacity.darkblue.replayFadeTime = 0
skinnopacity.darkblue.scraperInfo = 0
skinnopacity.darkblue.scrollMode = 0
skinnopacity.darkblue.tabsInDetailView = 0
skinnopacity.darkblue.tracksFadeTime = 0
skinnopacity.darkblue.useMenuIcons = 0

Alles anzeigen

Das Makefile ist Standard:

Code

# External image lib to use: imagemagick, graphicsmagick
#IMAGELIB = imagemagick
IMAGELIB = graphicsmagick

louis · 13. August 2021

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

S:oren · 13. August 2021

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.

Gruss,

S:oren

kamel5 · 13. August 2021

Zitat von Dr. Seltsam

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

Kann ich hier nachvollziehen, schaue ich mir an.

Zitat von louis

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.

Zitat von S:oren

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

kamel5 · 13. August 2021

Dr. Seltsam,

Zitat von Dr. Seltsam

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

ich habe einen Fix dazu commited, das sollte jetzt funktionieren. Bitte nochmal testen.

Grüße

kamel5

[SkinNopacity] Aktuelle Probleme

Jetzt mitmachen!

Teilen

Tags