Beiträge von Sven H

    Alles klar.
    Danke für deine Rückinfo. :smiling_face:


    Was mich nur stutzig macht, ist deine Aussage, dass es bis vor kurzem noch funktioniert hat.
    Da die stable 2.2 von 05/2016 ist und diese auch den "Fehler" hat, ist die Formulierung "vor kurzem" etwas komisch :face_with_tongue:


    Jetzt bin ich echt neugierig und warte meine Aufnahmen noch ab, um den Test mit den 3 Timern noch auszuführen.


    Hast du die Timer an der Box erstellt oder über den Webbrowser am PC?

    Dann frage ich jetzt nochmal, weil du darauf noch nicht konkret geantwortet hast.
    Hast du es mal ohne HDMI an der Box versucht? (also Kabel an der Box abziehen)


    Ich habe an der Box per HDMI einen Samsung-TV, an dem wiederum eine Heimkinoanlage von Samsung hängt.


    Bei meinen Tests waren sowohl TV als auch Heimkino-Anlage im einfachen Standby (wie bei der Box der Idle-Mode).
    Weiterhin hatte ich den Test auch ohne eine HDMI-Verbindung zum TV durchgeführt (HDMI-Kabel der Box am TV abgezogen).

    Hab ich ja schon mehrfach versucht. Allerdings bisher immer nur mit 2 Timern nacheinander.


    Fährt die Box bei 10min Abstand mit afterevent=auto zwischen den Aufnahmen überhaupt in den DeepStandby?


    Hatte daher bei meinen Tests mit 2 Timern beim 1. Timer immer afterevent=deepstandby gewählt.


    Bei Pausen zwischen den Timern von wenigen Minuten (glaube ich hatte max. 5min) bliebt die Box im Idle nach der 1. Aufnahme (wenn diese auch auf afterevent=auto stand) und wartete auf die 2. Aufnahme.
    Nach dem 2. Timer mit auto ging die Box dann aber wieder in den DeepStandby.

    Ich hab das mal bei mir versucht nachzustellen.
    Bei mir bleibt sie immer im Idle-Mode während der Aufnahme und geht dann wieder in den DeepStandby.
    (mit zig Versuchen, mit und ohne HDMI-Kabel, mit aktiviertem CEC und mit deaktiviertem CEC...)


    Habt ihr bei HDMI-CEC die Option "Einschaltzustände ignorieren" testweise auch mal aktiviert?
    Klingt ja fast so, dass die Box denkt, der TV ist an und deshalb schaltet sie sich auch ein.

    @Reichi


    So, habe das jetzt mal ohne Transparenz und weiterhin ohne Angabe einer BackGroundColor für das Labels probiert.
    Dabei tritt das Problem nicht auf. Das Label hat dann hier immer einen schwarzen Hintergrund.


    Nun habe ich aber mal die Textfarbe beider Labels auf grün geändert, da man dabei besser sieht,
    wie sich die aktuelle Farbe des EPG-List (SelectionBackgroundColor) um die Schrift im "key_green" sammelt.
    Beim oberen Label, was ich "key_gr" genannt habe, passiert das nicht, obwohl beide Labels im Skin identische Vorgaben haben.


    XML
    <widget font="Regular;22" halign="left" name="key_gr" position="380,672" size="200,30" foregroundColor="#00389416" transparent="1" />
    <widget font="Regular;22" halign="left" name="key_green" position="380,695" size="200,30" foregroundColor="#00389416" transparent="1"/>


    Also scheint doch beim Wechsel der SelectionBackgroundColor der EPG-List das "key_green" irgendwie die Selection-Background-Farbe zu bekommen, soweit das Label im Skin keine angegebene BackgroundColor hat und transparent ist.
    Wenn es ein reines Plugin-Code-Problem wäre, müsste sich dieses ja auch auf die Schrift des oberen grünen Textes oder des Textes vom gelben Button auswirken. Es betrifft aber komischerweise immer nur ein Label, wenn im Namen des Labels "green" vorkommt.


    Ich möchte das jetzt aber abschließen, da es ja mit Angabe einer BackgroundColor nicht auftritt und die Umstände des Szenarios des Auftretens es nicht als allgemeines Problem erscheinen lassen.
    Sonst hätten sich ja wie gesagt auch schon andere gemeldet. :smiling_face:
    Mir ist es auch nicht gelungen, das Problem mit CoolTVGuide mit reinen Skin-Anpassungen (Entfernen der Label-BackgroundColor) nachzustellen.

    Unabhängig von eurer neuen Diskussion mache ich Nachmittag mal ein paar Screenshots ohne Transparenz bei den Labels.
    Ich glaube, dann sieht man es deutlicher von wo die Labels (ohne bachgroundColor im Skin) während der Codeausführung bei .setText() plötzlich eine BackgroundColor bekommen.


    Ich hatte die Schriftfarbe für den key_green mal auf grün gesetzt. Da hat man dann beim Navigieren in der EPGList plötzlich die weißen Fransen um den grünen Text gesehen.

    @Reichi


    Die Farbe 00f4f4f4 ist die foregroundColor-Farbe (Textfarbe) der Labels.
    Eine BackgroundColor hatten alle nicht.


    Komisch ist nur, dass das Problem ja nur bei Labels mit dem Text "green" im widget-Namen (z.B. "key_green") auftritt.


    Die BackgroundColor bekommt dieses Label dann plötzlich von der aktuellen SelectionColor der EPG-List. (in den Screenshots eben "lachs" oder "weiß")


    Die anderen Labels sind davon komischerweise nicht betroffen, obwohl sie zeitgleich mit dem key_green neuen Text bekommen.


    Wie gesagt, wenn ich den Labels eine feste Backgroundcolor zuweise, passiert das nicht und ist damit für mich umgehbar.


    Fraglich ist eben nur, warum das nur Labels betrifft, die ein "green" im Widget-Name haben.

    Ich habe nochmal etwas rumgespielt.


    Es liegt irgendwie doch am fehlenden "backgroundColor" im Widget für die key_Labels mit "green" im Namen.
    Setze ich dort eine backgroundColor, kommt es nicht zu diesen Problemen.


    Irgendwie scheint da e2 bei bestimmten Wechsel der Auswahl der EPG-Liste die BackgroundColor des Labels anhand der selectColor des ausgewählten EPG-List-Feldes zu ändern, wenn das key-Label selbst keinen Hintergrund hat.
    In Verbindung mit Transparent sieht man es dann nur direkt um die Schrift herum, was dann wie fett aussieht.
    Deshalb hast du vorhin ja auch gemeint, dass da eine andere Backgroundcolor zu sein scheint, obwohl ich gar keine angegeben hatte.
    Das war aber die Farbe aus dem selektierten EPG-Feld.


    Warum das aber nur bei Labels mit "green" im Namen passiert, ist mir dennoch ein Rätsel. :face_with_tongue:
    Alle anderen key-Labels benötigen in Bezug auf dieses komische Verhalten nicht zwingend eine BackgroundColor.

    gut möglich. Ist ja aber auch nur bei bestimmten Wechseln der Auswahl in der EPG-Liste.


    Ich hab es ja auch nur gemerkt, weil ich den Skin ausgerichtet habe.
    Dabei fiel mir das dann bei den Texten auf, als die dranwaren bezüglich des Ausrichtens (Pos + Size).
    Da musste ich dann im EPG wandern, um die Texte unten zu ändern, um zu sehen, ob Pos. und Breite bei beiden Texten passt.

    Damit hat es alles gar nichts zu tun. :smiling_face:


    Es liegt am Namen des Widgets :face_with_tongue:
    Wenn da im Namen "green" enthalten ist, passiert es immer wieder.
    (hatte mit "key_green" und "green_txt" als zusätzliches Widget getestet).


    Nun heißt das widget "test_txt" und da kommt kein fetter Text.


    Muss doch irgendwo im e2-Code was drin sein, was nur bei "green" im Widget-Namen reagiert :smiling_face:


    Nachtrag:


    Hab jetzt nochmal ein zuätzliches Widget "green" angelegt und den Text für dieses parallel zum "test_txt" neu geschrieben.
    Während der Text im Feld "test_txt" normal angezeigt wird, kommt beim Feld "green" wieder "fetter" Text.


    Ich denke, damit ist es bewiesen :smiling_face:
    (e2 macht bei widgets mit "green" im Namen irgendwas komisches)

    Der Screen hat keinen Eintrag für BackgroundColor.

    XML
    <screen name="MultiEPG_MV_New" flags="wfNoBorder" position="0,0" size="1280,720" title="MultiEPG Vali-Mod">

    Und wenn ich die foregroundColor rausnehme, ist der Unterschied zu dem "fetten" Text noch deutlicher zu erkennen.


    Was ich nur nicht begreife, ist die Tatsache, warum der fette Text nur beim grünen Butten kommt, obwohl zur gleichen Zeit auch der Text für den gelben Button neu geschrieben wird.
    Hab schon mal die Reihenfolge geändert und ein komplett zusätzliches widget mit anderem Namen angelegt für den grünen Button-Text.
    Das hat aber alles nichts geändert- es kommt immer wieder der fette Text beim grünen Button, wenn ich die Auswahl in der EPG-Liste ändere.

    Ja, das ist ein von mir für OE2.5 angepasster MultiEPG-Vali-Mod, der ursprünglich nur bis OE2.0 funktionierte.


    Nein, andere Farben gibt es da nicht. Ich ändere lediglich die Farben für die aktuelle Auswahl in der EPGliste beim Wechsel von einem Nicht-Timer-Eintrag auf einen Timer-Eintrag und umgekehrt.


    So sind alle Farb-Button Beschriftungen im Skin gleich festgelegt.
    Deshalb verstehe ich nicht, wieso es da beim Wechsel des EPG-Eintrages plötzlich eine andere Schrift gibt (also fett oder was auch immer das sein soll) - und vor allem nur bei der Beschriftung für Grün.


    XML
    <widget font="Regular;22" foregroundColor="#00f4f4f4" halign="left" name="key_red" position="180,672" size="200,30" transparent="1" />
    <widget font="Regular;22" foregroundColor="#00f4f4f4" halign="left" name="key_green" position="380,672" size="200,30" transparent="1" />
    <widget font="Regular;22" foregroundColor="#00f4f4f4" halign="left" name="key_yellow" position="625,672" size="200,30" transparent="1" />
    <widget font="Regular;22" foregroundColor="#00f4f4f4" halign="left" name="key_blue" position="860,672" size="200,30" transparent="1" />


    und das ist der Code in der .py, um den Text der Beschriftung zu ändern:

    So, hier die Screenshots.


    1. Normaler Text bei "Timer setzen"
    2. "Fetter" Text bei "Timer setzen"
    3. "Fetter Text bei "Entferne Timer" und normaler Text bei "Timer bearbeiten" (obwohl dabei beide Inhalte der Labels im Code mit .setText() neu geschrieben wurden)


    Und das nur beim Wechsel des ausgewählten EPG-Eintrages mit rechts,links,hoch,runter.

    Kann ich das beeinflussen oder liegt das an Enigma?


    Sieht manchmal so aus, als wenn der Text doppelt ist und leicht versetzt übereinanderliegt.
    Die Schrift wirkt dann etwas vermanscht (könnte auch fett sein).