[SkinNopacity] Aktuelle Probleme

Danke fuer's Fixen.

Zitat von kamel5

- Im breiten Aufzeichnungsmenü gibt es ja nur eine Zeile und es werden auch keine Fehler angezeigt, nur das "!".

Ich sollte diese beiden Menüpunkte dann auch nur anzeigen, wenn "Schmales Menü" eingestellt ist.

Oder habe ich da noch was falsch verstanden?

Dann habe ich das falsch verstanden. Ja, es gibt das "!", das ist auch richtig so. In den Details zur Aufnahme stehen dann die Anzahl Fehler, aber das soll vermutlich nicht abschaltbar sein. Da habe ich die beiden Menues vermutlich verwechselt.

Wenn diese Einstellungen nicht angezeigt werden, wenn sie keinen Unterschied ergeben, dann wäre das wahrscheinlich weniger verwirrend.

Zitat von kamel5

- Das Kanallogo ist jetzt in der Lage konfigurierbar "Vertikale Ausrichtung" -> unten, mittig, oben.

Wenn Du hier beim Default-Theme "unten" einstellst, sollte sich gegenüber dem alten Branch nichts verändert haben (die Berechnung der Lage ist dann die Selbe).

Ich habe das wie vorher auf "unten" stehen. Der Logohintergrund ist jetzt eine(?) Zeile höher und der Radius von dem Logohintergrund oben-links hat dadurch einen anderen Mittelpunkt wie der Radius der Fensterbegrenzung daneben. Nur oben-links passt es nicht (etwas zu hoch), unten-links passt es , rechts faellt es ggf. nicht auf. Ich hoffe, das ist halbwegs verständlich erklärt. Muss ich sonst selber irgendwann debuggen, haengt vielleicht auch von den eingestellten Raendern usw. ab.

Zitat von kamel5

Es geht hier um jedes neue OSD (osd = CreateOsd()), genauer den ersten Flush() .

Da muesste ich jetzt nachschauen, wann man ein CreateOSD aufruft. Jedes Mal, wenn man ein OSD-Fenster oeffnet? Vermutlich schon, weil ja die Größe immer anders ist. Bei meinen Versuchen schien es mir, dass nach dem Senderwechsel der erste Aufruf etwas langsamer ist, aber das kommt vermutlich von der Abfrage von EPG und Timern und hat nichts mit Deinem Problem zu tun.

Zitat von kamel5

Diese erste Verzögerungszeit ist außerdem abhängig von der OSD Größe und nicht skinnopacity spezifisch, tritt allerdings nicht bei Nutzung eines anderen Ausgabeplugin auf. Dadurch schließe ich den Core-VDR ursächlich aus, und wenn man davon ausgeht, das auch die TT6400 selbst nicht Ursache ist, bleibt nur noch das dvbhddevice-Plugin übrig.

Das Debuggen des dvbhddevice-Plugin übersteigt aber im Moment meine Möglichkeiten.

Hm, wuerde ich mir schon genauer ansehen, nur habe ich diesen Effekt bei mir nicht. Bei mir gibt es keine "Gedenksekunde", oder ich merke es nicht.

Hast Du irgendwo den Patch zum Anzeigen der Verzoegerung? Am besten bei abgeschaltetem Einblendeffekt und ohne Threads, das kann ich aber sonst auch Einschalten, wo ich jetzt den selben Branch verwende. Vielleicht ist es doch ein Effekt durch die "verbotenen" Thread-OSD-Zugriffe!?

Gruss,

S:oren

Zitat von kamel5

Mit welcher Version ging es denn noch? Version 1.1.9 ist ja auch schon eine Weile raus, und bisher gab es dazu keine Meldungen.

Das Magick hier ein segfault liefert, hat erst einmal keine Bedeutung, da das alle Fehler einsammelt.

Was ich bräuchte, ist ein aussagekräftiger Backtrace. Dann könnte man sicher mehr dazu sagen.

Ich verwende MLD 5.5. testing.

Die 1.1.9 hat lange Zeit funktioniert mit VDR 2.4.7.

Dann gab es vor Kurzem ein Update auf VDR 2.6.1 und seit dem gehts nicht mehr.

Wenn Du mir sagts, wie ein backtrace geht, dann liefere ich ab...

Danke und Grüße

wayne

Zitat von kamel5

Anbei mal ein Patch für die Kanalanzeige, der die Zeit vom ersten Flush misst. Animation dabei global aus.

Bei mir sieht das dann so aus:

Mai 02 14:49:08 vdr[364594]: [364594] skinnopacity: First Flush(): 626 ms

Bei mir

May 2 20:33:33 rockpro64 vdr: [1547] skinnopacity: First Flush(): 331 ms

Diese Drittel-Sekunde (329 - 334 ms in 10 Versuchen) hatte ich bisher als normal und unvermeidbar angesehen - auf einem RockPro64 (arm64) und der S2-6400 hinter einem PCIe-Switch (PCI bridge: ASMedia Technology Inc. Device 1182).

Ob es sich bei den Zeiten lohnt, da bei mir weiter zu suchen?

Gruss,

S:oren

Zitat von kamel5

Du hattest irgendwo mal geschrieben, das Du ein 720p OSD benutzt, dann wäre das erklärbar, denn es hängt von der OSD Größe ab.

Jetzt mal mit 1080i probiert: 308 bis 325 ms.

Dann wieder mit 720p: 301 bis 331 ms.

Die Größenordnung bleibt.

Gruß,

Sören

Zitat von kamel5

Schon seltsam, ich würde es trotzdem aber erst einmal darauf beruhen lassen.

Die OSD-Größe "Folge Auflösung" scheint nicht (immer?) richtig zu funktionieren. Wenn ich die fest auf 1920x1080 stelle, dann sehe ich auch größere Zeiten (~745ms). Dann war das doch nur eine Einstellungssache bei mir, sorry.

Ist das OSD bei Dir schärfer (bunter, hübscher) mit 1080er als mit 720er Auflösung? Ich habe hier an meinem Test-VDR eh nur einen alten Fernseher mit 720er Panel, da sehe ich (bis auf "Geometriebesonderheiten" bei der Darstellung / Logogröße) keinen Unterschied. Ist aber tatsächlich deutlich langsamer.

Gruß,

Sören

Zitat von kamel5

Übrigens habe ich gerade festgestellt, das die Zeit auch vom Farbformat abhängt, bei ARGB4444:

1080: skinnopacity: First Flush(): 336 ms

720: skinnopacity: First Flush(): 150 ms

Schon sehr seltsam.

Bei ARGB4444 gehen ja nur halb so viele Daten ueber den Bus wie bei ARGB8888.

Habe gerade nochmal kurz in den Code geschaut, dvbhddevice hat tatsaechlich zwei verschiedene OSD-Implementierungen, die aber beide hardware-gerendert werden. Das hatte ich anders in Erinnerung.

Waere nochmal interessant, ob Software-Rendering bei modernen Mehrkernprozessoren nicht schneller ist. Wenn ich mal viel Zeit habe...

Gruss,

S:oren

Zitat von kamel5

Was ich bräuchte, ist ein aussagekräftiger Backtrace. Dann könnte man sicher mehr dazu sagen.

Hier mal ein erster backtrace...

...zweiter Versuch....

Ich würde den Skin auch gern mal anpassen, aber mit dem Paket von seahawk1986 und auch mit selbst kompiliertem Plugin bekomme ich ein:

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

und vdr startet nicht...

Installiert sind:

Könnt Ihr weiterhelfen?

Zitat von S:oren

Habe gerade nochmal kurz in den Code geschaut, dvbhddevice hat tatsaechlich zwei verschiedene OSD-Implementierungen, die aber beide hardware-gerendert werden.

Wenn man etwas laenger hinschaut, sieht man, dass das TrueColor-OSD eigentlich komplett vom VDR intern gerendert wird. Das dvbhddevice nimmt die VDR-gerenderten Pixmaps, konvertiert die ggf. von ARGB8888 in ARGB8565 oder ARGB4444 (je nach Einstellung im Setup), teilt das Ergebnis ggf. auf (weil die Buffer-Maximalgröße fuer einen Treiberaufruf 1MByte betraegt), und schickt das auf die Karte. Das Hardware-Rendering beschraenkt sich dann auf das Zusammenkopieren der Teile.

Zitat von kamel5

Ich habe jetzt als aktuelle Lösung ein zusätzliches Lock() Unlock() Paar vor die Animationsschleife gesetzt.

Das LOCK_PIXMAPS ist wirklich nur ein Mutex. Ja, das wird beim Flush im dvbhddevice gelockt. Aber wenn das zu Verzögerungen führt, dass muss ja ein anderer Thread auch gerade ein Lock auf dem Mutex haben. Aber welcher Thread sollte das sein, wenn nur ein einziger Thread sich mit dem OSD befasst?

Gruss,

S:oren

Zitat von Taipan

Ich würde den Skin auch gern mal anpassen, aber mit dem Paket von seahawk1986 und auch mit selbst kompiliertem Plugin bekomme ich ein:

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

und vdr startet nicht...

...das Problem habe ich hier schon beschrieben und einen Post über deinem einen backtrace geliefert...

wayne

Ah, ok ich lese dann mal mit...

Hallo wayne,

Der Backtrace ist recht nichtssagend.

Könntest Du bitte alle *.dbg Pakete für VDR + Plugins installieren, und dann noch einen erzeugen?

Also vdr-plugin-skinnopacity-dbg, vdr-dbg, ...

~ Markus