[SkinNopacity] Aktuelle Probleme

  • Ich befürchte halt, ob das nun ein Konfigurationsfehler ist oder nicht, das es Anwender gibt, die es genau so benutzen.

    Glaube ich nicht, weil der Anwender ja sicher nicht mit viel Mühe eigene Logos generiert hat, um nachher keinerlei Unterschied zu dem Verhalten ohne diesen ganzen Aufwand zu erzielen, weil doch noch der Hintergrund sichtbar ist, wenn kein Logo existiert.


    Und dann wird sich hier im Forum wieder beschwert, das etwas in einer neuen Version nicht mehr so geht wie vorher.

    Dann erklärt man halt, wie man es anders einstellen muss.


    Wenn man in diesem Fall kein Hintergrundlogo hat, wechseln sich beim Senderumschalten mal ein transformiertes Logo mit Hintergrund und ein transparentes Logo ab


    Natürlich kann man sagen, da muss der Anwender nachsteuern, ist das aber realistisch.

    Das ist meiner Meinung nach kein Fall, den das Plugin speziell behandeln muss. Wenn jemand eigene konvertierte Logos benutzt, dann ist das sicher ein fortgeschrittener Anwender, der problemlos alle vorhandenen Logos konvertieren kann. Macht das Skript das nicht automatisch so?

    Ansonsten ist es doch einfach, die allgemeinen Logos alle aus dem entsprechenden Pfad zu loeschen, wenn man sie unter keinen Umstaenden sehen will. Aber einfach alle vorhandenen Logos zu konvertieren, waere doch der normale Weg. Warum sollte man nur einen Teil der Logos konvertieren, und sich dann wundern, dass nicht alle konvertiert vorliegen?


    Und es gibt ja auch Sender, die ständig ihren Namen ändern, will man da auch ständig neue Logos generieren?

    Wenn Sender ihre Logos aendern, muss ich mir die neuen Logos besorgen, das kann man ja nicht vermeiden. Wenn ich konvertierte Logos benutze, dann starte ich halt auch noch das Konverterskript, das ist doch vergleichsweise einfach.

    Wenn die Sender nur den Namen aendern, dann setze ich einen Link auf das vorhandene Logo. Hab ich selbst generierte Logos, dann mache ich das im entsprechenden themenspezifischen Verzeichnis, sonst im allgemeinen Logoverzeichnis. Irgendwie verstehe ich die Frage nicht.


    Gruss,

    S:oren

  • Natürlich könnte man jetzt noch eine Weile über die Verantwortung der Anwender philosophieren:), das bringt uns hier aber nicht wirklich weiter.


    Deshalb will ich das mal aus einer anderen Richtung betrachten.

    Der Fall 3 ist ja nicht explizit eingebaut worden, sondern ist ein Ergebnis der vorhandenen Möglichkeiten und dessen Anwendung lässt sich auch nicht verhindern. Deshalb sollte er, auch wenn das nicht unbedingt die Standardversion ist, richtig funktionieren. Und das war bis vor der aktuellen Änderung der Fall. Entstanden ist das optische Problem ja dadurch, das es jetzt 2 verschiedene Koordinatensätze gibt. Ich habe auch bis jetzt nicht ganz verstanden, warum das nötig ist.

    Wenn es darum geht, die Logos in einer anderen Größe darzustellen, dann könnte das auch durch die vorhandene Skalierung realisiert werden.

    Wenn es darum geht, die Logos nicht zentriert über dem Hintergrund darzustellen, dann würde ich das für keine gute Idee halten, den das führt zu einer Inkompatibilität zu älteren Versionen und sieht unter Umständen bei großen Logos auch nicht gut aus.


    Das Standardverhalten sollte hier konform mit dem bisherigen Verhalten sein, zentriertes Hintergrundlogo und zentriertes 100% skaliertes Logo. Das wäre übrigens auch mein Favorit. Und dann gäbe es auch keine optischen Diskrepanzen. Alles Andere liegt in der Verantwortung des Anwenders, der könnte sich dann ja versetzte, einfarbige, krumme, was auch immer für andere Logos selbst generieren. Und die konvertierten Logos mit Rahmen sind ja auch nur ein Beispiel dafür.

    Für den Fall des versetzten Logos könnte man dem Anwender eine neue Setup-Option pixelweise vertikale/horizontale Verschiebung bereitstellen, das wäre aber ein anderes Thema.


    Grüße

    kamel5

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

    Git-Repo: gitlab.com/kamel5

  • wayne ,


    ich habe jetzt mal mein MLD aktualisiert. Und auch den Fehler gefunden.:)

    Es nützt ja nichts, wenn bei mld zwar das Plugin selbst installiert ist, aber keine Resourcen dazu im Verzeichnis /etc/vdr/plugins/skinnopacity.:wand

    Das solltest Du nachfordern. Dann geht es auch.


    Taipan ,

    schau mal, ob das bei Dir auch der Grund ist.


    Grüße

    kamel5

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

    Git-Repo: gitlab.com/kamel5

  • Ich habe das verlinkt (liegt bei yavdr unter /var/lib/vdr/plugins) aber der Fehler bleibt (bei mir mit softhdvaapi)

    Code
    1. /etc/vdr/plugins/skinnopacity
    2. └── themeconfigs
    3. ├── theme-darkredNG.conf
    4. ├── theme-default.conf
    5. ├── theme-iceblue.conf
    6. └── theme-light.conf
  • Da gibt es auch noch ein icons und ein symbols Verzeichnis, beide sind auch wichtig.

    Ich werde zwar noch eine Prüfung einbauen, der diesen Absturz verhindert, es wird dann aber trotzdem nicht richtig funktionieren, wenn nicht alle Resourcen da sind.


    Grüße

    kamel5

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

    Git-Repo: gitlab.com/kamel5

  • Ich habe die Verzeichnisse hinzugefügt, aber keine Änderung.

  • Liegen sie denn auch an der richtigen Stelle, das sie vom Plugin gefunden werden? Ich kenne mich da bei yavdr nicht aus, wo da sowas standardmäßig installiert und vom Plugin gesucht wird.


    Ansonsten, auch in diesem Fall hilft nur ein Backtrace.


    Grüße

    kamel5

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

    Git-Repo: gitlab.com/kamel5

  • Ich werde morgen mal bei seahawk1986 anfragen...

  • wayne ,

    Es nützt ja nichts, wenn bei mld zwar das Plugin selbst installiert ist, aber keine Resourcen dazu im Verzeichnis /etc/vdr/plugins/skinnopacity.:wand

    Das solltest Du nachfordern. Dann geht es auch.

    Hab's gefordert und es wurde prompt geliefert...;)8)


    Bei mir geht's nun wieder.


    Danke für die Unterstützung!


    Noch eine Anmerkung von Claus:

    Quote

    Beim Plugin selbst fehlt wohl eine Prüfung ob die Ordner vorhanden sind, um nicht mit nem Absturz zu reagieren, sondern eine Fehlermeldung auszugeben.

    streamdev-Server: MLD 5.5 testing, Mystique SaTiX-S2 V3 Dual + DuoFlex S2, J3160, 8GB, 60GB System,

    streamdev-Client 1: NUC6CAYH (Intel HD Graphics 500) + MLD 5.5 testing, One For All URC 7960,

    streamdev-Client 2: RPI4, MLD 5.5 testing, One For All URC 7960,

    Media-Server: Synology DS215j

    AV-Geräte: Hisense H65MEC5550, Dali Zensor 5 AX

  • wayne ,


    sehr schön, das es bei Dir jetzt geht.

    Quote

    Beim Plugin selbst fehlt wohl eine Prüfung ob die Ordner vorhanden sind, um nicht mit nem Absturz zu reagieren, sondern eine Fehlermeldung auszugeben.

    Eine Prüfung, ob Ordner vorhanden sind, die bei einem standardmäßigen "make install" installiert werden, halte ich nicht für notwendig. Den das gewährleistet ja nicht, das alle nötigen Dateien auch vorhanden sind.

    Was natürlich nicht in Ordnung ist, das es dann einen segfault gibt, und das werde ich in der nächsten Version fixen.


    Grüße

    kamel5

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

    Git-Repo: gitlab.com/kamel5

  • S:oren ,


    ich habe jetzt Deinen commit "Align channel logo background" mal nachvollzogen, manchmal dauert es halt etwas länger.;)

    Wenn Du die vertikale Anpassung noch für den Fall "dtBlending" machst, sollte es eigentlich auch keine Probleme beim Fall 3 mehr geben.

    Ich glaube, dann könnten wir diese Änderung abschließen und es so übernehmen.


    Grüße

    kamel5

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

    Git-Repo: gitlab.com/kamel5

  • Wenn Du die vertikale Anpassung noch für den Fall "dtBlending" machst, sollte es eigentlich auch keine Probleme beim Fall 3 mehr geben.

    Ich glaube, dann könnten wir diese Änderung abschließen und es so übernehmen.

    Ich habe ja schon mehrfach versprochen, das Misalignment noch zu fixen. Aber ich kann nicht versprechen, dass das diese Woche noch klappt.


    Gruss,

    S:oren

  • kamel5

    ...ich hatte erfolglos Kontakt mit seahawk1986 und jojo61 . Der Fehler liegt wohl bei Teilen der yaVDR-Gemeinde im Frontend softhd,-vaapi,-cuvid,-drm das auf dem Plugin von jojo61 basiert (irgendwas mit detach Option '-D'). Aber weil es niemanden sonst stört, oder keiner sonst die Konstellation in Betrieb hat bin ich da dann mal raus.


    Finde es aber trotzdem Klasse das Du und S:oren hier soviel Arbeit reinsteckt! :thumbup:

  • Taipan ,


    ja, dieses Problem gab es schon öfters bei verschiedenen Ausgabedevices. Bei einigen geht es jetzt und bei anderen nicht. Du könntest auch noch mal ein anderes Ausgabedevice probieren, wenn das möglich ist.

    Im Endeffekt ist das eindeutig ein Problem des Ausgabedevices, den wenn das ein OSD zurückgibt, dann muss das auch benutzbar sein.

    Ich könnte zwar auch einen Workaround in den Skin einbauen, wie ich es schon mal hatte. Das ist dann aber auch keine allgemeingültige Lösung, denn andere Skins könnten davon auch betroffen sein.


    Grüße

    kamel5

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

    Git-Repo: gitlab.com/kamel5

  • ...nach den Änderungen läuft der Skin nun - Danke nochmals :thumbup:

  • Danke, jetzt funktioniert es wie erwartet. Auch der viel diskutierte Fall 3 geht damit problemlos.

    Ansonsten waere vielleicht denkbar, den Logohintergrund (optional?) statt des nicht vorhandenen Logos zu laden, wenn ansonsten der Logohintergrund ausgeschaltet ist.

    Ich habe die Setup-Option "Hintergrund für Kanallogos benutzen" noch um 2 Möglichkeiten erweitert (abwärtskompatibel). Ich denke, das erhöht auf jeden Fall die Flexibilität. (letzter commit in meinem devel Branch)

    Es stehen jetzt die Möglichkeiten "nie", "immer", "wenn ein Kanallogo existiert" und "wenn kein Kanallogo existiert" zur Verfügung.


    OK, ich wollte Dich noch fragen, ob Du momentan noch akute Baustellen hast, ansonsten würde ich gerne noch ein neues Release machen, da ich die nächsten 8 Wochen etwas weniger Zeit haben werde.


    Aus meiner Sicht gibt es momentan noch 3 längerfristige Dinge:

    - die optische Ansicht bei Bildschirmauflösung < 1080

    - eliminieren von redundantem Code in der Detailansicht tabbed view und nicht tabbed view

    - Aktualisierung von Bildschirmbereichen im Menü, die nicht aktualisiert werden müssten


    Grüße

    kamel5

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

    Git-Repo: gitlab.com/kamel5