[SkinNopacity] Aktuelle Probleme

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


    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

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

    Git-Repo: gitlab.com/kamel5

  • Ich habe die Änderung mal getestet. Sieht gut aus! Es wird jetzt beim Umschalten zwischenzeitlich kein "SD" mehr angezeigt, auch die Auflösungen stimmen.

    Schöne Grüße

    Lothar

  • Hallo zusammen,


    ich nutze das Ausgabeplugin von Andreas von hier und nutze immer noch sehr gerne Skinnopacity.

    Leider habe ich hier auch das Problem, dass mir immer das Sysmbol 1080i angezeigt wird. Auf einen rpi3b+ funktioniert es richtig. Bei SD wird 576 und bei ARD HD wird 720...


    Wo ist der Fehler hier zu suchen? Fehlt dem softhddevice-drm Plugin noch eine Funktion?


    Gruß

    Uwe

  • 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

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

    Git-Repo: gitlab.com/kamel5

  • Genau, GetVideoSize ist (noch) nicht implementiert. Sollte aber kein Problem sein.


    Gruß

    Andreas

  • Genau, GetVideoSize ist (noch) nicht implementiert. Sollte aber kein Problem sein.

    Habs versucht einzubauen und soweit ich sehe, funktionierts.

  • Habs versucht einzubauen und soweit ich sehe, funktionierts.

    Hab es gerade getestet, funktioniert hier nun auch von 567i bis UHD! Vielen Dank rell  :thumbup:

  • Gerade ein Invalid Lock im Log gesehen - erstes Auftreten (nach GIT Pull um den 20.12.):

    Trat auf, als nach Abspielen einer Aufnahme Zwecks Marken-Edit, zurück auf Live-TV geschaltet wurde.


    Grüße,

    Stefan

  • 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

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

    Git-Repo: gitlab.com/kamel5

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

  • kamel5

    Bisher ein Einzelfall, hab wegen des Deadlock-Problems aber noch nicht versucht, es zu reproduzieren.


    Aufzeichnungsmenü ist geteilt (links Aufnahme / rechts Beschreibung), denke also ja.


    Einstellungen (setup.conf):

    /var/lib/vdr/plugins/skinnopacity als Anlage


    Stefan

  • 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:

    Code
    1. 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

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

    Git-Repo: gitlab.com/kamel5

  • kamel5 :

    Habe jetzt Deinen letzten Commit in Master gepacht. Bisher kein Lock Error.


    Danke,

    Stefan


    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.

  • Bisher kein Lock Error.

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

    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

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

    Git-Repo: gitlab.com/kamel5