Posts by kls

    Wie bisher auch, über OsdCurrentItem():

    Der Fehler, dass beim Drücken eines Hotkeys (0-9) das aktuelle Menü nochmal dargestellt wird, dürfte hiermit behoben sein:

    Diff
    --- osdbase.c   2025/01/16 09:42:11     5.2 
    +++ osdbase.c   2025/01/28 12:55:08 
    @@ -501,7 +501,6 @@ 
             if (*s == Key - k1 + '1') { 
                current = item->Index(); 
                RefreshCurrent(); 
    -            Display(); 
                cRemote::Put(kOk, true); 
                break; 
                }

    So wie's aussieht könnte das hier die Lösung für das Problem mit den zu frühen OsdCurrentItem()-Aufrufen sein:

    Diff
    --- menuitems.c 2024/07/13 09:12:18     5.2 
    +++ menuitems.c 2025/01/28 11:58:07 
    @@ -38,7 +38,6 @@ 
    { 
      cString buffer = cString::sprintf("%s:\t%s", name, Value); 
      SetText(buffer); 
    -  cStatus::MsgOsdCurrentItem(buffer); 
    } 
    
    void cMenuEditItem::SetHelp(const char *Red, const char *Green, const char *Yellow, const char *Blue)

    MarkusE Magst du das bitte mal testen?
    An den anderen Punkten bin ich noch dran.

    Ich habe den Patch vdr-2.7.3-status-osditem_3.diff.txt angewendet und das Beispielplugin "status" so geändert:

    Wenn ich damit die Menü-Taste drücke erscheint im Log:

    Mal abgesehen davon, dass OsdHelpKeys zweimal kommt (dem werde ich nachgehen), kommt OsdCurrentItem erst nach allen OsdItem2.
    Drücke ich jetzt '7' kommt

    was etwas verwundert, da erst das Hauptmenu nochmal kommt (dem werde ich auch nachgehen), aber danach kommen auch wieder alle OsdItem2 vor dem OsdCurrentItem.

    Wähle ich dann '1' sehe ich

    Auch hier wird das Menü zweimal gelistet (wie oben), und ich denke mal, es sind die Zeilen

    Code
    OsdCurrentItem Language:#0110 
    OsdCurrentItem Language:#011English 
    ...

    am Anfang, die die Probleme machen, oder?

    Also OsdItemSelected_2.txt geht mir irgendwie zu weit. Vielleicht sollten wir uns nochmal zurücklehnen und klären, was das eigentliche Problem hier ist.

    In cOsdMenu::Display() wird cStatus::MsgOsdItem() für alle Items im Menu aufgerufen, mit dem jeweiligen Index und (neuerdings) mit der Info, ob sie selektierbar sind.
    Ein cStatus-Objekt hat keine Information darüber, wie viele Zeilen das OSD darstellen kann, und welche Items momentan sichtbar sind.
    cStatus::MsgOsdCurrentItem() wird mit dem Text des selektierten Items aufgerufen. Hier fehlt eigentlich der Index. Genau genommen könnte man sich hier den Text sparen, weil ja zuvor schon alle Texte mitgeteilt wurden, aber dann müsste ein cStatus, das nur an dem aktuell selektierten Text interessiert ist, alle Texte speichern, was unnötiger Aufwand wäre.

    Wenn sich Text auf einem OSD, das gerade gebaut wird, aber noch nicht angezeigt wird, ändert, dann wird keine Methode aufgerufen. Also im oben genannten Fall 2b.

    cStatus hat kein Konzept von "noch nicht angezeigt". Wie oben geschildert bekommt es die Info über alle Items, und welches selektiert ist. Mehr nicht. Eine neue Funktion cStatus::OsdCurrentItem2(const char *Text, int Index) wäre also akzeptabel, alles weitere übersteigt eigentlich das Konzept von cStatus.

    Ja, es wird gerundet:

    int cVideoDirectory::VideoDiskSpace(int *FreeMB, int *UsedMB)
    {
      ...
      return (free + used) ? round(double(used) * 100 / (free + used)) : 0;
    }

    Wenn free==0 ist, dann kann auch 100 zurückgegeben werden.
    Die genauen Werte hängen natürlich davon ab, was das System liefert. Diese Zahlen sind nicht aufs Byte genau.

    Wie muss ich also vorgehen, um zu prüfen ob der garbage collector das event schon gelöscht hat?

    Gar nicht ;-).
    Wenn ein Event in den Garbage-Collector kommt, wird beim nächsten Umlauf (einmal pro Sekunde) der Hauptschleife dem Timer ein neuer (oder kein) Event zugewiesen. Der alte Event bleibt mindestens 5 Sekunden im Garbage-Collector. Wenn also der Timer einen Pointer auf einen Event hat, dann darf der auch dereferenziert werden. Allerdings nur die "erste Stufe". Ich hatte kürzlich einen Fall, wo Timer->event->Schedule()->PresentSeenWithin() in einem Rutsch dereferenziert wurde, aber da der Event bereits aus seinem Schedule entfernt war, war event->Schedule() zu dem Zeitpunkt bereits NULL. Hab's dann gestaffelt abgefragt und das Problem war behoben.

    Als "Anzeigefehler" würde ich das nicht bezeichnen. Der 12-Uhr-Event hat running status 4 (und immer nur der), also wird er als erster angezeigt. Der zweite ist der in der Liste darauf folgende.

    Versuch doch mal, in eit.c nach der Zeile "// Drop bogus events..." das Statement

    if (Duration > 10 * 3600) continue;

    einzufügen. Damit sollten solche Events ignoriert werden und alles wieder normal funktionieren (bis auf VPS). Vor dem Start der so geänderten Version solltest du die epg.data löschen.

    So wie's aussieht wird auf diesen Kanälen der "running status" immer auf diesen überlagernden Event gesetzt. Somit sind keine VPS-Aufnahmen möglich. Schaltet man VPS in den Timern ab, wird normal zeitgesteuert aufgenommen. Ich habe testweise in eit.c mal diese langen Events ignoriert, aber auch dann bekommt der aktuelle Event keinen running status 4.

    Bei "alt_Das Erste" sieht es bei mir so aus:

    Ich denke mal, da kann man drüber streiten, ob das ein Fehler ist (und von wem). Der Sender wird demnächst abgeschaltet, ist also obsolete, und darauf wollen sie deutlich hinweisen. Daher wohl der erste Event, der alle weiteren dieses Tagen "überlagert".

    SHF Wie sollte sich denn VDR deiner Meinung nach hier verhalten?