Dokumentation von virtual void cStatus::OsdCurrentItem(const char *Text)

  • Dann wäre es vielleicht besser, wenn das item zurückgeben würde, ob sich etwas geändert hat.

    Z.B. könnte state = item->ProcessKey(kNone);  state == osUnknown zurückgeben, wenn sich das item nicht geändert hat.

    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

  • Wir wollen jetzt besser nicht in operative Hektik verfallen ;-).
    Die eOSState Werte dienen dazu, nach "oben" zu melden, wie es weitergehen soll, nicht, ob sich das Item verändert hat. Hier auf kNone abzufragen erscheint mir sinnvoll und funktioniert in meinem Test auch. Weitergehende Änderungen möchte ich an der Stelle aber nicht machen.

  • Inzwischen denke ich auch, dass ein zusätzlicher Parameter (Index) zu MsgOsdCurrentItem die beste Lösung ist.

    Der attachte Patch (OsdItemSelected_3.txt) macht folgendes:

    • Löschen des Aufrufs cStatus::MsgOsdCurrentItem(buffer); aus menuitems.c (cMenuEditItem::SetValue(const char *Value) )
    • Ergänzen von virtual void OsdCurrentItem2(const char *Text, int Index)

    Bisherige Tests sehen sehr gut aus, ich werde natürlich weiter testen ...

  • Danke, das wäre auch mein nächster Schritt gewesen ;-).

    Anbei zum Abgleich der komplette Stand der Änderungen bzgl. Statusmeldungen.
    Bei den Aufrufen von MsgOsdCurrentItem() habe ich anstatt Item->Index() den jeweils an dieser Stelle bereits vorhandenen Wert genommen, da Index() die Liste durchläuft und "zählt", was hier aber unnötig ist, da der Wert bereits bekannt ist.

  • Bei den Untersuchungen zum Thema cStatus ist mir noch aufgefallen, dass beim Scrollen jedes Mal für alle Items OsdItem2() aufgerufen wird, was an dieser Stelle völlig unnötig ist. Beiliegender Patch (nach vdr-2.7.3-status-01.diff.txt anzuwenden) behebt das.
    MarkusE Magst du dir das bitte auch anschauen? Ich versuche jetzt noch herauszubekommen, warum das Menü bei ersten Mal manchmal zweimal aufgebaut wird (habe ich erst durch die doppelten Aufrufe von OsdItem2() gesehen). Das ist auch unnötig und vermutlich auch ohne Verwendung von cStatus schlecht für die Performance.

  • Jetzt habe ich doch noch etwas gefunden:

    • Menü Kanäle
    • Nach unten scrollen (scroll bar) und einen Kanal markieren (Blaue Taste), z.B. 1714 ITV1 HD
    • 2 Nach unten
    • Dann OK drücken

    Als Ergebnis steht dann:

    1716 ITV1 HD

    also wie erwartet. Zwei Zeilen darunter steht aber auch noch

    1714 ITV1 HD :( .

    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

  • Auf Anhieb kann ich das nicht nachvollziehen.
    Kannst du mir eine channels.conf schicken, mit der das auftritt?

    Ist das ein neuer Fehler (durch vdr-2.7.3-status-02.diff.txt verursacht), oder tritt das auch mit Version 2.7.3 auf?

    <edit>
    Kann es sein, dass du das nicht im OSD beobachtest, sondern nur über die cStatus-Meldungen?
    Da fehlt andscheinend ein Neuaufbau über OsdItem2(). Schau ich mir an.
    </edit>

    Mach mit beim VDR User Counter! Jetzt mit OpenStreetMap!

    Edited once, last by kls (February 11, 2025 at 11:04 AM).

  • Es ist ein neuer Fehler (durch vdr-2.7.3-status-02.diff.txt verursacht).

    Kann es sein, dass du das nicht im OSD beobachtest, sondern nur über die cStatus-Meldungen?
    Da fehlt anscheinend ein Neuaufbau über OsdItem2().

    Ja, genau das ist es.

    Also, manchmal findet der Neuaufbau über OsdItem2 statt, und manchmal nicht.

    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

Participate now!

Don’t have an account yet? Register yourself now and be a part of our community!