[SkinNopacity] Aktuelle Probleme

  • S:oren , danke für den Patch.

    Ein erster Test bei mir war erfolgreich.

    Ich habe den Patch in meinen devel-Branch übernommen.


    shofmann , bitte testen, ob das bei Dir auch funktioniert.


    Grüße

    kamel5

    VDR 2.6.6: ASUS Prime X470-PRO, Ryzen 7 5700X, 64GB, 6TB HD, GT1030, Fedora 39 Kernel 6.7 X86_64, Devicebonding 2 x 1 auf 2, TT6400, DVBSky S952 V3

    Git-Repo: gitlab.com/kamel5

  • Ohne Patch funktionierte das letzte auch mit skinnopacity.

    Mir ging es nicht darum, was man aufrufen kann oder nicht. Ich wollte wissen, ob man beim Standard-VDR ohne Patches auch so einen Absturz provozieren kann.


    Das scheint mir eigentlich ein Problem des Core-VDR zu sein. Warum sollte man einen Menueeintrag (sichtbar oder nicht) updaten (die Darstellung auf ausgewaehlt aendern), wenn das Menue sowieso durch die Auswahl geschlossen wird? So ein Update verlangt aber der VDR-Core. Und das ist eigntlich nur sinnvoll, wenn gescrollt werden soll, nicht bei einer Auswahl mit Zifferntasten.


    Aber mein Workaround sollte den Absturz auch fixen.


    Gruss,

    S:oren

  • Mir ging es nicht darum, was man aufrufen kann oder nicht. Ich wollte wissen, ob man beim Standard-VDR ohne Patches auch so einen Absturz provozieren kann.

    Ah, OK. Ohne Patches kann man so einen Absturz nicht provozieren, es ist mir bisher zumindest nicht gelungen.

    Das scheint mir eigentlich ein Problem des Core-VDR zu sein. Warum sollte man einen Menueeintrag (sichtbar oder nicht) updaten (die Darstellung auf ausgewaehlt aendern), wenn das Menue sowieso durch die Auswahl geschlossen wird? So ein Update verlangt aber der VDR-Core. Und das ist eigntlich nur sinnvoll, wenn gescrollt werden soll, nicht bei einer Auswahl mit Zifferntasten.

    Das Updaten der Menüeinträge hat folgenden Grund:

    Wenn man z.B. den Eintrag 10 aktiv hat und sich dann mit der 4 die Aufzeichnungen anzeigen läßt und dann mit der Zurück-Taste wieder in das Hauptmenü zurück springt, ist dann der Menüeintrag 4 aktiv (das ist auch die Erwartungshaltung).


    Es kann aber durchaus sein, das sich da noch einiges optimieren ließe. Bei den Standard-Skins ist das bisher wahrscheinlich nicht aufgefallen, weil dort die Menüeinträge nicht separat behandelt werden, es wird also nur das angezeigt, was der VDR selbst liefert.

    Aber mein Workaround sollte den Absturz auch fixen.

    Da die anderen von mir getesteten Skins (ich habe nicht alle getestet) das Problem nicht haben, ist ein Workaround für mich mehr als OK.


    Grüße

    kamel5

    VDR 2.6.6: ASUS Prime X470-PRO, Ryzen 7 5700X, 64GB, 6TB HD, GT1030, Fedora 39 Kernel 6.7 X86_64, Devicebonding 2 x 1 auf 2, TT6400, DVBSky S952 V3

    Git-Repo: gitlab.com/kamel5

  • Das Updaten der Menüeinträge hat folgenden Grund:

    Wenn man z.B. den Eintrag 10 aktiv hat und sich dann mit der 4 die Aufzeichnungen anzeigen läßt und dann mit der Zurück-Taste wieder in das Hauptmenü zurück springt, ist dann der Menüeintrag 4 aktiv (das ist auch die Erwartungshaltung).

    Das klappt aber auch so, wenn ich das Update unterdruecke (vor dem Schliessen des Menues und oeffnen des neuen), wie jetzt hier.


    Ist halt nicht optimiert, aber ohne Absturz ist das dann auch nicht so schlimm.


    Gruss,

    S:oren

  • Hallo kamel5, S:oren,


    vielen Dank für den Patch, er hat bei einem ersten schnellen Test keinen Absturz mehr verursacht. Ich werde den Patch lokal erst einmal beibehalten und das Verhalten die nächsten Tage beobachten. Ich erwarte aber nicht, dass sich noch Probleme zeigen werden.


    Einen Absturz kann man vermutlich auch mit dem Standard-VDR ganz leicht produzieren: Einfach die Zahl der Hauptmenü-Elemente so einstellen, dass sie nicht mehr auf eine Seite passen und einen Eintrag auf einer nicht angezeigten Folgeseite auswählen.


    Ausprobiert habe ich das zwar nicht mit dem "originalen" VDR v2.6.1, sondern indem ich bei meinem gepatchten VDR die Zahl der Hauptmenü-Elemente pro Seite auf 3 geändert habe (die minimal zulässige Zahl). Nach Anzeige der ersten Seite und direkter Auswahl von Menüpunkt Nr. 4 (Taste "4", erstes Element auf Seite 2) bzw. Menüpunkt Nr. 7 (Taste "7", erstes Element auf Seite 3) ist der VDR ebenfalls abgestürzt. Beim direkten Zurückspringen (also beispielsweise mit den Pfeiltasten den Menüpunkt Nr. 7 auswählen, kurz aufrufen, per "Exit" zurück ins Hauptmenü und dann per Taste "4" direkt auf das erste Element auf der Seite davor springen) treten ebenfalls Abstürze auf.


    Als Gegenprobe habe ich 15 Elemente pro Seite eingestellt und bei direkter Auswahl von Element Nr. 17 (Tastenfolge "1", "7") ebenfalls einen Absturz provozieren können.


    Beides deutet darauf hin, dass nicht der Menu-Selection-Patch ursächlich ist, sondern nur die Tatsache, dass man ein nicht angezeigtes Element auf einer anderen Seite als Seite 1 direkt auswählt. Mit dem Patch war aber auch in diesen Szenarien alles gut.


    Viele Grüße

    Stefan



    PS: Die andern von mir genutzten Skins haben, wie bereits weiter oben erwähnt, ein solches Verhalten bislang nicht gezeigt. Vor SkinNopacity habe ich meist SkinEnigmaNG genutzt und mir auch mal SkinElchi, LCars oder LCarsNG angesehen.

    Hardware: Antec NSK2480, Asus P8B75-M LX, Intel Core i5-3570T, 4 GB RAM, NVIDIA GT610, TT-Premium S2-6400, 128 GB SSD, 14 TB HDD, Pioneer BDR-207EBK
    Software: Ubuntu 20.04 LTS mit Kernel 5.15 und VDR 2.6.6 (mit offiziellen und eigenen Patches)
    Plugins: devstatus, dvbhddevice, dvd, dvdswitch, epgsearch, extrecmenu, recsearch, femon, live, markad, mlist, osdteletext, remote, screenshot, skinenigmang, skinnopacity, streamdev, systeminfo, undelete, xineliboutput
    Addons: VDR Convert 0.1.0 (angepasst)

  • Danke für die Rückmeldung.

    Einen Absturz kann man vermutlich auch mit dem Standard-VDR ganz leicht produzieren: Einfach die Zahl der Hauptmenü-Elemente so einstellen, dass sie nicht mehr auf eine Seite passen und einen Eintrag auf einer nicht angezeigten Folgeseite auswählen.

    Ja, das dürfte die gleichen Abstürze verursachen.

    Beides deutet darauf hin, dass nicht der Menu-Selection-Patch ursächlich ist, sondern nur die Tatsache, dass man ein nicht angezeigtes Element auf einer anderen Seite als Seite 1 direkt auswählt. Mit dem Patch war aber auch in diesen Szenarien alles gut.

    Genau so ist es, der Menu-Selection-Patch hat es nur zum Vorschein gebracht.

    PS: Die andern von mir genutzten Skins haben, wie bereits weiter oben erwähnt, ein solches Verhalten bislang nicht gezeigt. Vor SkinNopacity habe ich meist SkinEnigmaNG genutzt und mir auch mal SkinElchi, LCars oder LCarsNG angesehen.

    Wie das andere Skins gemacht haben, habe ich mir nicht angesehen, es ist aber so, das Skins, die keine eigene Verwaltung von Menüelementen implementiert haben, wie z.B. LCARS, von diesem Problem grundsätzlich nicht betroffen sind.

    Im Endeffekt könnte man diesen Absturz sicher auch im Core-VDR beheben und vielleicht wäre das sogar die bessere Lösung. Da wir hier aber jetzt einen Fix haben, sehe ich da im Moment keinen Handlungsdruck.


    Grüße

    kamel5

    VDR 2.6.6: ASUS Prime X470-PRO, Ryzen 7 5700X, 64GB, 6TB HD, GT1030, Fedora 39 Kernel 6.7 X86_64, Devicebonding 2 x 1 auf 2, TT6400, DVBSky S952 V3

    Git-Repo: gitlab.com/kamel5

  • Sehe ich genauso. Danke nochmals an euch beide für die schnelle Hilfe.


    Viele Grüße

    Stefan

    Hardware: Antec NSK2480, Asus P8B75-M LX, Intel Core i5-3570T, 4 GB RAM, NVIDIA GT610, TT-Premium S2-6400, 128 GB SSD, 14 TB HDD, Pioneer BDR-207EBK
    Software: Ubuntu 20.04 LTS mit Kernel 5.15 und VDR 2.6.6 (mit offiziellen und eigenen Patches)
    Plugins: devstatus, dvbhddevice, dvd, dvdswitch, epgsearch, extrecmenu, recsearch, femon, live, markad, mlist, osdteletext, remote, screenshot, skinenigmang, skinnopacity, streamdev, systeminfo, undelete, xineliboutput
    Addons: VDR Convert 0.1.0 (angepasst)

  • Macht doch einen neuen Thread, mit der Beschreibung des Fehlers im Core-VDR.

    Klaus sollte das fixen.

    Client1: ASUS P5QC, Dual Core 3G, Cine S2, Ext. Board von TBE, Xubuntu 20.04, VDR 2.6x

    Client2: RPI3

    Server: RPI4, Sundtek SkyTV Dual 2x

  • Ich nehme das mal mit auf meine Liste. Vorher muss ich mir aber noch einen Testfall ausdenken, der auch mit ungepatchem VDR zum Absturz führt.


    Grüße

    kamel5

    VDR 2.6.6: ASUS Prime X470-PRO, Ryzen 7 5700X, 64GB, 6TB HD, GT1030, Fedora 39 Kernel 6.7 X86_64, Devicebonding 2 x 1 auf 2, TT6400, DVBSky S952 V3

    Git-Repo: gitlab.com/kamel5

  • Auf dem Tab "Besetzung" werden alle Schauspieler gezeigt, auch wenn es kein Bild gibt.

    Könntest Du das ändern, und nur Schauspieler mit Bild zeigen?


    Eine vollständige Liste ohne Bilder kann man ja in einem anderen Tab anzeigen, oder unten im Tab "Besetzung" noch die fehlenden Schauspieler nennen, ohne Platz für die Bilder zu lassen, die es eh nicht gibt.

    Client1: ASUS P5QC, Dual Core 3G, Cine S2, Ext. Board von TBE, Xubuntu 20.04, VDR 2.6x

    Client2: RPI3

    Server: RPI4, Sundtek SkyTV Dual 2x

  • MarkusE , das gefällt mir auch nicht so richtig.

    In diesem Bereich hatte ich mir sowieso für den Herbst mal eine Überarbeitung vorgenommen, es gibt da noch redundanten Code zwischen tabbed und nicht tabbed Anzeige. Bei der Gelegenheit werde ich mir das mit den Schauspielern auch mit ansehen.

    Ich werde dann die Schauspieler ohne Bild einfach weglassen, da dieser Reiter ja hauptsächlich die Bilder anzeigen soll. Außerdem gibt es eh nie aller "Teilnehmer".


    Grüße

    kamel5

    VDR 2.6.6: ASUS Prime X470-PRO, Ryzen 7 5700X, 64GB, 6TB HD, GT1030, Fedora 39 Kernel 6.7 X86_64, Devicebonding 2 x 1 auf 2, TT6400, DVBSky S952 V3

    Git-Repo: gitlab.com/kamel5

  • Neue Version 1.1.12 im git:


    - Add display volume to DisplayMenu, DisplayChannel and DisplayReplay

    - Display number of recordings in recordings main menu

    - Some optical optimitation

    - Fix segfault when tvscraper returns "call->type = tNone"

    - Fix segfault when selecting invisibile menu items


    Grüße

    kamel5

    VDR 2.6.6: ASUS Prime X470-PRO, Ryzen 7 5700X, 64GB, 6TB HD, GT1030, Fedora 39 Kernel 6.7 X86_64, Devicebonding 2 x 1 auf 2, TT6400, DVBSky S952 V3

    Git-Repo: gitlab.com/kamel5

  • Hi,


    ich hätte da einen Feature-Request.

    Wäre es möglich in den Menüs Programm,Kanäle, Aufzeichnungen, Timer - sprich allen Menüs mit mehrzeiligen Menüpunkten und Kanalinfo - die Zeilenanzahl übers Setup optional zu machen?

    Hintergrund ist der, das auf dem TV für deutlich mehr Zeilen Platz wäre wenn ich die Zusatzinfos zur laufenden Sendung und ggflls. den Fortschrittsbalken usw. ausblenden könnte. Ähnlich ist es bei den Aufzeichnungen. Vielleicht wäre bei der Schriftgrößeneinstellung ein Wert "off" denkbar der die Zeile komplett ausschaltet!? Bei meinem TV sind 9-10 Zeilen EPG usw eingestellt und da sind die Menüpunkte doch sehr "mächtig". Wenn ich zu viel wähle gibts Mäusekino/Drängelei bei den Schriften...

  • ich hätte da einen Feature-Request.

    OK.

    Ich muss aber nochmal nachfragen, ob ich das richtig verstanden habe.

    Du möchtest bei einem Menüpunkz, z.B. EPG, der jetzt aus Uhrzeit , Titel, Untertitel und Fortschrittsbalken besteht, diese einzelnen Punkte deaktivieren können.


    Grüße

    kamel5

    VDR 2.6.6: ASUS Prime X470-PRO, Ryzen 7 5700X, 64GB, 6TB HD, GT1030, Fedora 39 Kernel 6.7 X86_64, Devicebonding 2 x 1 auf 2, TT6400, DVBSky S952 V3

    Git-Repo: gitlab.com/kamel5

  • :thumbup: genau! Das ist in shady auch eine Option. Und wenn Logo und (nur) Titel zu sehen sind könnten 18+ Menüpunkte möglich sein (85 Zoll)...

    2 Mal editiert, zuletzt von Taipan ()

  • Ich muß nochmal nerven ;)

    ich habe weiter noch das kleine Problem, das beim Plugin osdserver und fritzbox die Einträge inklusive Überschriften alle linksbündig "gedrängt" werden. Die Plugins starten im Vollbild und da wäre deutlich mehr Platz verfügbar...

    Kann man die Zeilen unterscheiden/unterschiedlich ausrichten - vielleicht Überschriften farblich hinterlegt zentriert und Listeneinträge etwas vom Rand weg?


    vdr-portal.de/index.php?attachment/46922/vdr-portal.de/index.php?attachment/46923/


    Zum Vergleich shady:


    vdr-portal.de/index.php?attachment/46926/

  • Hallo,

    Ich muß nochmal nerven

    kein Problem.


    ich kann Deine Bilder leider nicht anzeigen -> "Seite nicht gefunden".

    Wenn ich das allerdings bei mir anzeigen lasse, sieht das bei fritzbox unter skinnopacity und shady genau gleich aus.


    Grüße

    kamel5

    VDR 2.6.6: ASUS Prime X470-PRO, Ryzen 7 5700X, 64GB, 6TB HD, GT1030, Fedora 39 Kernel 6.7 X86_64, Devicebonding 2 x 1 auf 2, TT6400, DVBSky S952 V3

    Git-Repo: gitlab.com/kamel5

  • Hi,

    ich sehe gerade das der "Bock" etwas anders ist und ich nicht weiß ob es überhaupt Sache Deines Skins ist!

    Ich habe FB-Tasten zugewiesen für Fritzbox und die Haussteuerung (osdserver). Bei aktivem Shady und dem Direktaufruf der Plugins über die definierten Tasten sieht alles schick aus mit zentrierten Überschriften usw. Aber beim Aufruf der Plugins aus dem Menü heraus ist alles nach links gequetscht!


    Das ist die Ansicht in shady wie ich sie "gut" finde:



    BTW: Sind die Bilder nun sichtbar?

  • BTW: Sind die Bilder nun sichtbar?

    Ja.

    Ich habe FB-Tasten zugewiesen für Fritzbox und die Haussteuerung (osdserver). Bei aktivem Shady und dem Direktaufruf der Plugins über die definierten Tasten sieht alles schick aus mit zentrierten Überschriften usw. Aber beim Aufruf der Plugins aus dem Menü heraus ist alles nach links gequetscht!

    Das ist schon seltsam. Im Moment fällt mir nichts dazu ein. Der Skin zeigt normalerweise hier nur an, was er angeboten bekommt, und das sollte sich in beiden Fällen nicht unterscheiden, da das nur als fester Text übergeben und angezeigt wird.

    Ich müsste bei Gelegenheit mal schauen, ob es da im skindesigner eine Sonderbehandlung gibt...


    Grüße

    kamel5

    VDR 2.6.6: ASUS Prime X470-PRO, Ryzen 7 5700X, 64GB, 6TB HD, GT1030, Fedora 39 Kernel 6.7 X86_64, Devicebonding 2 x 1 auf 2, TT6400, DVBSky S952 V3

    Git-Repo: gitlab.com/kamel5

  • Mach Dir da mal keinen Streß! Ist unter diesen Umständen wohl eher als Luxusproblem abzufertigen...


    Was viel wichtiger ist: Tolle Arbeit an Skinnopacity :thumbup:

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!