Posts by S:oren

Bei mir ist alles aehnlich. Ich benutze auch transparente Hintergruende, weil skinnopacity den Hintergrund separat (nach Theme) laden kann. Bei dem default-Theme ist dort die Standard-Logogroesse bei 720p-Wiedergabe ohne Overscan am Fernseher 184x130, somit erzeuge ich mir die Logos gleich passend, da muss zumindest fuer die groessten vorkommenden Logos nicht mehr zur Laufzeit skaliert werden. Mehrfaches Skalieren erzeugt eben (manchmal?) Ueberraschungen mit einem Pixel(?) Versatz (Rundungsfehler?). Da der Rand bei mir 3 Pixel gewaehlt ist, faellt das dann auf.

Gut zu wissen, dass es aktuell immer noch mehrere gepflegte Logo-Repositories gibt, wenn doch mal irgendwas nicht mehr aktuell gehalten wird. Das Skript zur Konvertierung auf die Namen der channels.conf finde ich richtig gut. Ich habe sowieso nur 40 Sender (2 Seiten im EPG) in meiner channels.conf, nicht die ueber 1000 bei Astra 19.2E oder ein paar Hundert bei KD-DVB-C, die ich sowieso nie anschaue.

Vielen Dank nochmal fuer die Skripte, ich habe seit langer Zeit wieder paasende aktuelle Logos, sehr schoen!

Gruss,

S:oren

MegaV0lt wrote:

Du verwendest Picons2VDR.sh. Hier geht es um Picon.cz2VDR.

Oh, wie bin ich denn da hin gekommen? Ist mir nicht aufgefallen, dass es da 2 verschiedene Varianten mit subtilem Namensunterschied gibt. Dann bitte meine unpassenden Anmerkungen ignorieren.

Was sind denn die Vor- und Nachteile der beiden Skripte?

MegaV0lt wrote:

Hast Du eventuell mal zum Vergleich zwei Logos mit den Einstellungen aus dem original Skript und Deinen Änderungen?

Besonders aufgefallen war mir das beim Logo fuer Kabel1. Wenn ich mir jetzt nochmal die generierten Logos mit Vorgabe-Geometrie ansehe, da gibt es zwar einen Unterschied mit und ohne meinen Patch, aber beides sieht nicht unbedingt falsch aus. Nach nochmaligem Skalieren in skinnopacity sieht man eine leichte Verschiebung nach rechts, das kann aber auch eher Zufall abhaengig von der exakten Skin-Logogroesse sein. Ich hatte Versionen mit weniger Rand als bei der Vorgabe-Geometrie ausprobiert, weiß aber die exakten Einstellungen nicht mehr. Jetzt benutze ich "LOGO_CONF=(184x130 176x124 dark transparent)" (Warnungen zum fehlenden exakten Hintergrund ignoriert, kein Problem weil transparent), da ist der Patch nicht unbedingt noetig. Von mir aus kannst Du den alten Code so lassen, auch wenn der einfachere Code mit Patch fuer mich mindestens genau so gut funktioniert. Diese Diskussion ist ja sowieso im falschen Thread, weil ich ja das Skript ohne .cz benutzt habe.

Habe auch leider erst jetzt Deine Antwort sehen, es gibt anscheinend wieder mal keine Mail-Benachrichtigungen vom Portal mehr.

Gruss,

S:oren

Erstmal: Vielen Dank fuer das Script!

Die korrekte Zuordnung der offenbar aktuellen picon-Logos zu den tatsaechlich vorhandenen Sendern in der channels.conf finde ich wirklich gelungen.

Leider scheinen die Logos nicht perfekt zentriert zu sein. Hab das nicht genauer untersucht oder verstanden, folgender Quick-Hack macht es fuer mich richtiger:

Der "Rand" wird ja durch die beiden Geometrien fuer Gesamt- (Hintergrund) und (eigentliche) Logogroesse definiert. Ich brauche die Logos allerdings fuer skinnopacity, evt. sind die Raender und Aspect-Ratios dort anders als bei SkinFlatplus.

Ansonsten, oder auch damit im Zusammenhang, scheinen ein paar Einstellungen zu LOGO_CONF zusammengefasst zu sein.

MegaV0lt wrote:

LOGO_TYPE -> Hintergrund (Vorgabe transparent)

LOGO_SIZE -> Logogröße (Vorgabe: 220x132)

LOGO_PACKAGE -> Empfangsart (Vorgabe: 19.2E) Beispiel bei Empfang von 2 Satelliten: LOGO_PACKAGE=(19.2E 9.0E)

scheint es so nicht mehr zu geben. Was an sich nicht schlimm ist, eher im Gegenteil, nur passt die Doku nicht mehr ganz.

MegaV0lt wrote:

Ich hoffe es gefällt den einen oder anderen.

Ja, sehr. Hatte mich lange nicht darum gekuemmert, aber jetzt habe ich wieder aktuelle Logos gleich mit richtigem Namen, sehr schoen!

Gruss,

S:oren

kamel5 wrote:

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

kamel5 wrote:

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

kamel5 wrote:

Es scheint so, das das Auswählen eines Menüeintrages, der gerade nicht angezeigt wird, zum Absturz führt.

Ja, klar. Meine Frage war, ob das auch bei Standard-Skins ohne Patches so ist.

Wie auch immer, ich habe einen Patch fuer skinnopacity in meinen Test-Branch eingecheckt. Also bitte testen.

Gruss,

S:oren

shofmann wrote:

Wenn ich einen der Einträge auf den Positionen ab 11 über die Pfeiltasten anwähle, ist alles in Ordnung. Wenn ich aber einen Eintrag auf "Seite 2" direkt durch Zifferneingabe der Menüposition auswähle (Menu-Selection-Patch), also bspw. von 1 nach 18 springen möchte, stürzt der VDR reproduzierbar ab.

Funktioniert das mit den "Standard-Skins"? Und ohne Menu-Selection-Patch (auf zweite Seite gehen und dann per Zahl einen Eintrag der ersten Seite aufrufen)?

Ich habe nicht genug Menueeintraege, um das hier zu testen...

Gruss,

S:oren

OK, hoffentlich komme ich diese Woche noch dazu...

Habe bei mir die Anzahl der sichtbaren auf die Anzahl der benoetigten Menueeintraege angepasst, mir gefielen die Scrollbalken dort nicht. Aber ja, Abstuerzen sollte es nicht. Wobei der menuselection-Patch ja nicht wirklich "Original"-VDR ist...

Gruss,

S:oren

kamel5 wrote:

Ich habe eine Weile überlegt, ob ich das mache, andererseits sind alle anderen Branches bei mir auch klein geschrieben...

Finde ich prinzipiell gut, aber "remotes/origin/Devel-Light" gibt's noch

Gruß,

Sören

Endlich konnte ich die neue Version ausprobieren.

Die ganze Lautstaerkeanzeige ist großartig! Die "vollstaendige" Version gefaellt mir besser als die einfache, aber das ist ja einstellbar. Das war das letzte Feature, was mir bei diesem Skin noch gefehlt hatte.

Bei einem kurzen Test habe ich auch keine sonstigen Probleme feststellen koennen. (Dass der alte Devel-Branch jetzt devel heisst, war etwas verwirrend...)

Vielen, vielen Dank!

S:oren

kamel5 wrote:

Das ist recht simpel.

OK, funktioniert bei mir. Da ist auch nichts kaputt.

Ich kann mich aber erinnern, dass es mit dem grab ein Bandbreitenproblem auf der Karte gab. Deshalb muss man es extra einschalten.

Vielleicht hat es mit der Video-/OSD-Aufloesung zu tun, ob das grab funktioniert oder nicht!?

Gruß,

Sören

kamel5 wrote:

Hier müsste man vorab klären, ob das vom Core-VDR aus überhaupt möglich ist.

Ich bin mir da ziemlich sicher, skinelchi kann das.

Gruß,

Sören

kamel5 wrote:

Bezüglich ".i2c_rate = SAA716x_I2C_RATE_400", lassen sich da eigentlich auch Zwischenfrequenzen einstellen, oder sind die beiden Werte fest vorgegeben?

Das sind die Werte aus dem I2C-Standard (Standard-Mode, Fast-Mode). Der SAA7160 selbst koennte vermutlich auch Fast-Mode-Plus (1 MBit/s) und alles dazwischen (mehr oder weniger exakt). Normalerweise stellt man immer den schnellsten Modus ein, den alle Busteilnehmer unterstuetzen.

Die I2C-Frequenz beeinflusst schon irgendwie die zeitlichen Ablaeufe auf dem PCIe-Bus mit VDR, aber wenn es ein OSD-Problem auch mit langsamstem I2C gibt, wird eine andere Frequenz da nur zufaellig etwas verbessern oder verschlechtern.

kamel5 wrote:

Vielleicht könntest Du das bei Gelegenheit mal ausprobieren.

Muss ich erstmal wieder herausfinden, wie das genau geht...

Gruß,

S:oren

kamel5 wrote:

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)

Ich habe noch keine Zeit gefunden, das auszuprobieren. So wie den ganzen Devel-Branch.

kamel5 wrote:

OK, ich wollte Dich noch fragen, ob Du momentan noch akute Baustellen hast

Nein.

Eine Anzeige der Lautstaerkeeinstellung ueber anderen Menues waere evt. noch schoen. Verwende das aber nur bei einem meiner VDRs, sonst Lautstaerke direkt ueber Fernseher.

Gruß,

S:oren

kamel5 wrote:

Was sich jetzt verändert hat, ist die Häufigkeit des Auftretens. Durch diese Änderung ".i2c_rate = SAA716x_I2C_RATE_400" tritt das Problem deutlich häufiger und umfangreicher auf. Ich weiß nicht, ob es da einen logischen Zusammenhang geben kann.

Das OSD hat nichts mit dem I2C zu tun. Sieht eher nach einem Hardwareproblem aus. Eventuell koennte helfen, die S2-6400 nicht komplett ganz in den PCIe-Slot zu stecken, sondern um einen halben Millimeter weniger. Wenn das einen Unterschied macht, dann vorsichtig den Loetstopplack von den PCIe-Pins abkratzen, vorsichtig einen halben Millimeter an der Kante zu den freiliegenden Pins, nur den Lack, nicht die Vergoldung.

kamel5 wrote:

Die VDR Bildschirm-Grab Funktion (svdrpsend grab):

Das hat bei mir noch nie mit der TT6400 funktioniert.

Da gibt es einen Modulparameter, um das Grab (single-shot) einzuschalten. Hatte mal vor langer Zeit funktioniert. Hab's seitdem nicht wieder ausprobiert.

Wenn das OSD kaputt ist, kann das selbe Hardwaereproblem natuerlich auch das Grab beeinflussen. Hab sonst keine Idee im Moment dazu.

Gruss,

S:oren

S:oren wrote:

Ich habe ja schon mehrfach versprochen, das Misalignment noch zu fixen.

Ich denke, ich hab den Bug gefunden. Neue Version in meinem -test-Branch...

Gruss,

S:oren

kamel5 wrote:

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

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.

kamel5 wrote:

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.

kamel5 wrote:

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?

kamel5 wrote:

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

kamel5 wrote:

Der Ausgangspunkt war ja, die "doppelte" Darstellung von Hintergrundlogo und konvertiertem Logo.

Wenn das so bleibt, braucht auch nichts geändert werden.

"Wenn das so bleibt, braucht auch nichts geändert werden." Das verstehe ich nicht in dem Zusammenhang.

Die "doppelte" Darstellung von Hintergrundlogo und konvertiertem Logo (Fall 3) ist ein Konfigurationsfehler und kann einfach dadurch geloest werden, dass man entweder (Fall 1) die Anzeige des Hintergrundlogos abschaltet, oder (Fall 2) originale statt konvertierte Logos verwendet (die themenspezifischen Logos loescht oder ohne eingebetteten Hintergrund generiert). Je nachdem, ob man bei nicht vorhandenem Logo (z.B. durch Aenderung des Sendernamens) den leeren Hintergrund sehen will (Fall 2) oder nicht (Fall 1). Beides ganz einfach vom Nutzer umzusetzen, keinerlei Aenderung am Plugin noetig.

Gruss,

S:oren

kamel5 wrote:

Dann könnte man alle Varianten abbilden, die es jetzt auch gibt.

Mit mehr Einstelloptionen genau die selben Varianten abbilden, die es jetzt auch schon gibt!? Bin ich der Einzige, der das komisch findet?

Gruss,

S:oren