[SkinNopacity] Aktuelle Probleme

Zitat von LotharE

Eins ist mir noch aufgefallen: Während des Umschaltens liefert GetVideoSize() manchmal 0x0. Dann wird der Default sd576i gezogen.

Ich habe mir das mal angesehen, und das Default jetzt auf kein Icon geändert.

In dem Zusammenhang habe ich diese Icon-Selection mal von Abfrage der Videobreite auf Abfrage der Videohöhe umgestellt (wie im skindesigner).

Das scheint mehr Fälle abzudecken.

Es wäre schön, wenn Du mal testen könntest, ob das jetzt so passt (letzter commit im Branch devel).

Zitat von 9000H

bleibt noch DVB-T2 mit 1080p da wird noch 1080i angezeigt.

Das lässt sich leider nicht aus der Videosize ableiten. Die einfachste Möglichkeit wäre hier, die Auflösung 1080 ohne i bzw. p anzuzeigen...

Grüße

kamel5

Uwe ,

skinnopacity wertet wie z.B. auch der skindesigner das Ergebnis der Funktion "cDevice::PrimaryDevice()->GetVideoSize(screenWidth, screenHeight, aspect);" aus. Das Ausgabedevice müsste diese Werte korrekt befüllen, sonst funktioniert das nicht.

Grüße

kamel5

Fourty2,

in dem Bereich hat sich zwar schon länger nichts geändert...

OK, ich muss mal sehen, ob ich das reproduzieren kann.

Grüße

kamel5

Zitat von Fourty2

Das langsame Ausblenden des OSD arbeitet wieder (weiß garnicht mehr, wann das zuletzt funktionierte),

Dann ist es Version 1.1.9. Das Ausblenden dürfte noch nie funktioniert haben, das habe ich mit eingebaut.

Auch das Einblenden ist vorher noch nie richtig gegangen, jetzt sollten alle OSD-Elemente berücksichtigt werden...

Aber zurück zum Thema:

Ich konnte bisher den "invalid lock sequence report" bei mir nicht nachvollziehen.

Ich habe dazu zwar eine Idee, es wäre aber hilfreich wenn ich das hier testen könnte.

Schicke mir deshalb mal Deine Skin-Einstellungen, möglicherweise gibt da einen Parameter, der das provoziert.

Und dann noch die Frage, ob es bei Dir reproduzierbar ist, oder nur ein Einzelfall, dann wird es schwieriger zu finden.

Lässt Du das Aufzeichnungsmenü ersetzen?

Grüße

kamel5

Fourty2 ,

ich habe Deine Skin-Einstellungen mal getestet und konnte es auch damit im normalen Betrieb nicht nachvollziehen.

Es liegt also nicht an den Einstellungen.

Vielleicht ist daran auch ein plugin beteiligt. Denn dieser Aufruf:

Jan  8 14:17:48 vdr: [2868] /usr/bin/vdr cMenuRecording::RefreshRecording() calling ?? at ??:0

wird bei Anzeige der Aufnahme-Info sekündlich aufgerufen und macht normalerweise nichts. Hier wäre interessant, wodurch das "RefreshRecording()" bei Dir mit Aktualisierung der Anzeige ausgelöst wurde. Nachdem ich diese Aktualisierung der Anzeige erzwungen habe, konnte ich auch den Report nachvollziehen.

Aber egal, es ist auf jeden Fall problematisch, in SetRecording() im Skin ein höherwertiges Lock zu machen. Das sollte nur in der Funktion Flush() stattfinden.

Ich habe das jetzt entsprechend geändert.

Es wäre schön, wenn Du den Branch devel (aktuell letzter commit) bei Dir mal nutzen und beobachten könntest. Damit sollte dieser "invalid lock sequence report" nicht mehr auftreten.

Viele Grüße

kamel5

Zitat von Fourty2

Bisher kein Lock Error.

Sehr schön, dann werde ich das so übernehmen.

Zitat von Fourty2

PS:

Hatte auch die Fehleranzeige (aus 4c4cdb98e662c69d..) probiert, leider sieht man die Fehler nicht, weil die zwei Zeitdauern bereits zuviel Platz brauchen, wenn man das Menü nach goldenem Schnitt teilt.

Habe mir dies daher zur Aufnahmezeit (wie im Original) verschoben, da paßt es besser.

Klar, irgendwann reicht der Platz nicht mehr. Ich muss mal sehen, ob mir da eine flexiblere Lösung einfällt.

Grüße

kamel5

Hallo,

nachdem es hier schon länger scheinbar keine akuten Probleme gibt, habe ich den letzten Stand mal zu Version 1.1.10 gemacht.

- Height and width confused (thx to LotharE at vdr-portal.de)

- Prevents "invalid lock sequence" in the recording info menu when Skinnopacitys SetRecording is called

- Optimize display timers in main menu

- Optimize display channellogo in displaychannel

- Added number of errors to recording item in the recordings menu

- Size of channel logos is now configureable in setup to better fit in postion

Grüße

kamel5

Zitat von wayne

VDR exits at So Apr 24 17:18:26 CEST 2022
Magick: abort due to signal 11 (SIGSEGV) "Segmentation Fault"...

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.

Grüße

kamel5

Hallo S:oren ,

Danke fürs Rückmelden.

Zitat von S:oren

Folgende Kleinigkeiten sind mir noch aufgefallen:

- typo im Kanalwechsel-Menue-Setup: Schriftgr_ä_ße bei den letzten beiden Eintraegen

- mit breitem Aufzeichnungsmenue scheinen die Einstellungen fuer die Fehleranzeige nicht zu wirken (0 Fehler anzeigen aus, 2./3. Zeile ??)

- Der Kanallogo-Hintergrund im Kanalwechselmenue sitzt bei mir jetzt minimal zu hoch. Das kann doch eigentlich nichts mit der neuen Logogröße zu tun haben!? Eher mit dem anderen Branch?

- Typo habe ich geändert.

- 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?

- 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).

Zitat von S:oren

Hieß das, die erste Ausgabe nach dem Start des VDR, oder nach jedem Kanalwechsel? Gab es da noch eine Idee, an welcher Abfrage von anzuzeigenden Details das liegt?

Es geht hier um jedes neue OSD (osd = CreateOsd()), genauer den ersten Flush() . Der erste Flush() kann auch durch ein cPixmap::Lock() ersetzt werden.

Hier ein Beispiel: Default-Theme, Kanalanzeige ein- und ausblenden mit "OK" -> 550ms für den ersten Lock(), danach 0ms.

Mai 02 12:15:43 vdr[8036]: [112701] DisplayChannel thread started (pid=8036, tid=112701, prio=high)
Mai 02 12:15:44 vdr[8036]: [112701] skinnopacity: First Lock(): 550ms
Mai 02 12:15:44 vdr[8036]: [112701] DisplayChannel thread ended (pid=8036, tid=112701)
Mai 02 12:15:51 vdr[8036]: [112755] DisplayChannel thread started (pid=8036, tid=112755, prio=high)
Mai 02 12:15:51 vdr[8036]: [112755] skinnopacity: First Lock(): 0ms
Mai 02 12:15:51 vdr[8036]: [112755] DisplayChannel thread ended (pid=8036, tid=112755)

Das Ganze ist mir aufgefallen, weil auch beim Einblenden kleiner OSD's immer der erste Step sehr groß war.

Ich habe jetzt als aktuelle Lösung ein zusätzliches Lock() Unlock() Paar vor die Animationsschleife gesetzt. Das führt zu einer deutlich flüssigeren Animation. Das reicht natürlich nicht für eine flüssige Animation des Hauptmenüs, hier ist wohl eher die Datenrate zur Karte das begrenzende Element, die kleineren OSD's (Kanalanzeige, Tonspuren u.ä.) gehen damit aber recht ordentlich.

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.

Grüße

kamel5