cTimer::StartTime() gibt inkonsistente Zeiten zurück.

  • Hi,

    bei VPS Timern gibt cTimer::StartTime() manchmal die VPS Zeit (event->Vps()), und manchmal die Event Start Zeit (event->StartTime() ) zurück.

    Je nachdem, mit welchen Parametern bool cTimer::Matches(time_t t = 0, bool Directly = false, int Margin = 0) aufgerufen wurde, bevor cTimer::StartTime() aufgerufen wird.

    Aus meiner Sicht sollte cTimer::StartTime() bei VPS Timern immer die VPS Zeit zurückgeben, in der timers.h steht ja: "the start time as given by the user". Und der User muss die VPS Zeit eingeben, wenn ein VPS Timer funktionieren soll.


    ~ Markus

  • Der Testfall wäre ein VPS Timer, bei dem "StartTime()" aufgerufen wird.

    • Erwartetes Ergebnis: Die VPS Zeit
    • Tatsächliches Ergebnis: event->StartTime()
  • Bliebe noch zu klären, ob eine solche Änderung irgendwelche ungewollte Nebenwirkungen haben kann. Immerhin läuft das schon seit vielen Jahren so ;-).

    Möglicherweise ist ja auch der Kommentar "as given by the user" nicht ganz korrekt.

  • Ich versuche jetzt mal, das derzeitige Verhalten korrekt zu beschreiben:

    Erstmal eine Definition: Die default Werte von startTime und stopTime sind die Werte, die Matches() setzt, also der Aufruf von Matches() mit den default Parametern.

    Methode eTimerMatch cTimer::Matches(const cEvent *Event, int *Overlap):

    In dieser Methode wird Matches(UseVps ? Event->Vps() : Event->StartTime(), true);, also nicht mit den default Parametern, gerufen. Das führt dann zu nicht-default Werten von startTime und stopTime.

    Am Ende der Methode wird dann startTime = stopTime = 0; gesetzt, was dazu führt, dass beim nächsten Aufruf von cTimer::StartTime() wieder die default Werte von startTime und stopTime gesetzt werden. Immerhin.

    Aber, was wenn ein Plugin Entwickler nicht weiß, dass er nach dem Aufruf von Matches() mit nicht default Parametern startTime = stopTime = 0 setzen muss? Und schlimmer noch, er kann diese Werte gar nicht ändern, es sind ja private Member Variablen von cTimer :( .

    Methode bool cTimer::SetEventFromSchedule(const cSchedules *Schedules):

    Da wird Matches(0, true); gerufen. Am Ende wird startTime und stopTime nicht explizit auf 0 gesetzt. Na ja, immerhin wird normalerweise Matches(e, &overlap); gerufen, was, wie oben geschrieben, startTime = stopTime = 0; setzt. Müsste also passen.

    Außer: Es wird kein Event in (TimeFrameBegin, TimeFrameEnd) gefunden. Das könnte z.B. nach einem Start (Neustart des Rechners) von VDR passieren, wenn die Events noch nicht bekannt sind, z.B. weil der User epg.data auf einer RAM disk hat, die nach dem Neustart weg ist.

    Wird also normalerweise gut gehen. Falls es mal (sehr selten) nicht gut gehen sollte, wird es der Anwender nicht reproduzieren können, es gibt dann also auch keinen bug Report ...

    Methode const cTimer *cTimers::GetMatch(time_t t) const:

    Da wird ti->Matches(t) aufgerufen, bei vielen lokalen Timern, die nicht aufnehmen. Am Ende wird startTime und stopTime nicht explizit auf 0 gesetzt.

    Falls danach jemand bei einem dieser Timer StartTime() aufruft, kann er etwas anderes bekommen, als wenn er StartTime() vor dem Aufruf von cTimers::GetMatch() gerufen hätte. :( .


    Das waren jetzt die Aufrufe von Matches(...) in timers.c. Und dann gibt es da noch Aufrufe außerhalb von timers.c . Und dann noch die Aufrufe der Plugin-Entwickler ...

  • Vorschlag:

    2 neue Methoden, cTimer::StartTime2(time_t t = 0) und cTimer::StopTime2(time_t t = 0) .

    Diese Methoden geben immer die dem Anwender im UI angezeigten Zeiten zurück. Bei wiederholenden Timern in Abhängigkeit von t.

    Diese Methoden rufen Matches(...) NICHT auf, und ändern auch nicht startTime und stopTime.

    Das wäre dann mal ein Anfang, und jeder Aufrufer von StartTime()/ StopTime() kann überprüfen, ob die neuen Methoden das zurückgeben, was er braucht.

  • Post by kls (June 27, 2025 at 5:02 PM).

    This post was deleted by the author themselves (June 27, 2025 at 5:03 PM).
  • > Und wo dort? "Timers", "Edit timer" oder das Hauptmenü der LCARS Skin?

    Ich hätte jetzt erwartet, dass an allen diesen Stellen die gleichen Zeiten für Start / Stop eines Timers angezeigt werden. Ist das nicht so? Welche Zeiten werden denn wo angezeigt?

  • cTimer::StartTime2

    Ich finde nicht kommentierte Funktionen mit einer Zahl dran ja nicht so toll.
    Könnte man daraus nicht cTimer::ProgrammedStartTime o.ä. machen? Also eine Funktion, die einen selbsterklärenden Namen hat?

    Display Spoiler
    Display Spoiler
    Display Spoiler
    Display Spoiler
    Display Spoiler
    Display Spoiler
    Display Spoiler
    Display Spoiler
    Display Spoiler
    Display Spoiler
    Display Spoiler
    Display Spoiler
    Display Spoiler
    Display Spoiler
    Display Spoiler


    to spoil
    verderben
    beschädigen
    plündern
    behindern
    berauben
    vereiteln
    rauben
    zerstören [fig.] [verderben, verunstalten]
    vergällen
    verhageln [fig.]

  • wirbel Ich gehe noch nicht davon aus, dass diese beiden Funktionen überhaupt kommen.

    MarkusE In "Timers" und "Edit timer" werden cTimer::Start() etc. verwendet. In LCARS cTimer::StartTimeEvent(), welches ggf. StartTime() aufruft. An welcher Stelle kommt denn nicht das, was du erwartest?

  • Macht das aus Usability Sicht Sinn, dem Anwender in LCARS etwas anderes anzuzeigen als in "Timers" und "Edit timer"?

    Wenn z.B. in meiner Fernsehzeitung steht, dass "Tatort" die VPS Zeit 20:15 hat, und ich dann Tatort mit VPS 20:15 programmiere, und dann später in LCARS als Startzeit 20:13 sehe, würde mich das irgendwie irritieren.

  • Im Hauptmenü von LCARS wollte ich eine Übersicht über die Timer haben, in der ich sehe, wann diese starten/stoppen. Gerade bei VPS-Timern kann das oft ziemlich weit von der VPS-Zeit abweichen und auch die Reihenfolge total verändern. In der LCARS-Übersicht werden übrigens auch keine inaktiven Timer angezeigt. Eben nur die aktiven Timer, in der Reihenfolge, wie sie tatsächlich starten (abhängig vom tatsächlichen "running status" kann es da dann letztendlich natürlich auch wieder zu Abweichungen kommen).

  • OK, dann muss ich genauer werden:

    cTimer::StartTime2(time_t t = 0):

    Gibt bei single event timern die Zeit zurück, die durch start und day eindeutig definiert ist.

    Gibt bei nicht single event timern die Startzeit des nächsten (falls t==0) bzw. des nächsten nach t startenden Timers zurück, die mit start, weekdays und t eindeutig definiert ist.

  • Ich sehe ehrlich gesagt die Notwendigkeit hiervon nicht. Wozu brauchst du das?

    Oder anders gefragt: an welcher Stelle in VDR erwartest du eine andere Zeitanzeige, als sie jetzt erfolgt?

    OK, das hast du eigentlich in #14 schon gesagt. Aber ich finde, für den Benutzer ist es informativer zu sehen, wann der Timer tatsächlich startet.

  • > Ich sehe ehrlich gesagt die Notwendigkeit hiervon nicht. Wozu brauchst du das?

    Gegenvorschlag: Lösche doch cTimer::StartTime() und cTimer::StopTime()

    Diese Methoden geben zufällige Zahlen zurück, und sollten daher nicht verwendet werden.

  • Aber ich finde, für den Benutzer ist es informativer zu sehen, wann der Timer tatsächlich startet.

    Vielleicht würde es ja auch so eine Änderung tun

    Code
    --  time_t StartTime(void) const; ///< the start time as given by the user
    --  time_t StopTime(void) const; ///< the stop time as given by the user
    ++  ///< StartTime() and StopTime() reflect the actual start time of the timer.
    ++  ///< They might be updated from SI tables, but this is not
    ++  ///< guaranteed.
    ++  time_t StartTime(void) const;
    ++  time_t StopTime(void) const;
    Display Spoiler
    Display Spoiler
    Display Spoiler
    Display Spoiler
    Display Spoiler
    Display Spoiler
    Display Spoiler
    Display Spoiler
    Display Spoiler
    Display Spoiler
    Display Spoiler
    Display Spoiler
    Display Spoiler
    Display Spoiler
    Display Spoiler


    to spoil
    verderben
    beschädigen
    plündern
    behindern
    berauben
    vereiteln
    rauben
    zerstören [fig.] [verderben, verunstalten]
    vergällen
    verhageln [fig.]

  • Das Thema ist in der Tat ein "Minenfeld".

    MarkusE In SetEventFromSchedule() macht ein startTime = stopTime = 0; wohl wirklich Sinn.

    wirbel Den Kommentar werde ich anpassen.

    Insgesamt schlage ich folgendes vor:

    Weitere Änderungen würde ich nur machen, wenn ein tatsächlicher Fehler auftritt, bei dem eine Aufnahme nicht wie erwartet funktioniert.

Participate now!

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