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

MarkusE · June 26, 2025 at 7:56 AM New

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

kls · June 27, 2025 at 11:22 AM New

Das würde ich ohne ausführliche Untersuchung und ggf. einem Testfall, bei dem sich etwas nicht wie erwartet verhält, ungern anfassen.

MarkusE · June 27, 2025 at 1:42 PM New

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

Erwartetes Ergebnis: Die VPS Zeit
Tatsächliches Ergebnis: event->StartTime()

kls · June 27, 2025 at 2:56 PM New

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.

MarkusE · June 27, 2025 at 3:51 PM New

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 ...

MarkusE · June 27, 2025 at 4:07 PM New

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.

kls · June 28, 2025 at 11:17 AM New

Quote from MarkusE

Diese Methoden geben immer die dem Anwender im UI angezeigten Zeiten zurück

Welches Menu meinst du mit "UI"?

MarkusE · June 28, 2025 at 12:34 PM New

> Welches Menu meinst du mit "UI"?

Das VDR OSD

kls · June 28, 2025 at 3:06 PM New

Undo wo dort? "Timers", "Edit timer" oder das Hauptmenü der LCARS Skin?

MarkusE · June 28, 2025 at 4:46 PM New

> 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?

wirbel · June 28, 2025 at 5:23 PM New

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?

kls · June 28, 2025 at 8:31 PM New

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?

MarkusE · June 28, 2025 at 8:44 PM New

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.

kls · June 28, 2025 at 10:20 PM New

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).

MarkusE · June 28, 2025 at 11:41 PM New

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.

kls · June 29, 2025 at 11:24 AM New

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.

MarkusE · June 29, 2025 at 12:02 PM New

> 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.

wirbel · June 29, 2025 at 7:45 PM New

Quote from kls

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;

kls · June 29, 2025 at 11:33 PM New

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:

Diff

--- timers.c    2025/01/13 14:44:18     5.25
+++ timers.c    2025/06/29 21:03:11
@@ -947,6 +947,7 @@
            Matches(0, true);
            time_t TimeFrameBegin = StartTime() - EPGLIMITBEFORE;
            time_t TimeFrameEnd   = StopTime()  + EPGLIMITAFTER;
+           startTime = stopTime = 0;
            for (const cEvent *e = Schedule->Events()->First(); e; e = Schedule->Events()->Next(e)) {
                if (e->EndTime() < TimeFrameBegin)
                   continue; // skip events way before the timer starts
--- timers.h    2025/03/02 11:03:35     5.12
+++ timers.h    2025/06/29 21:24:00
@@ -98,8 +98,8 @@
   bool Matches(time_t t = 0, bool Directly = false, int Margin = 0) const;
   eTimerMatch Matches(const cEvent *Event, int *Overlap = NULL) const;
   bool Expired(void) const;
-  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
+  time_t StartTime(void) const; ///< the start time of this timer, which may be adjusted for VPS timers
+  time_t StopTime(void) const; ///< the stop time of this timer, which may be adjusted for VPS timers
   time_t StartTimeEvent(void) const; ///< the start/stop times as given by the event (for VPS timers), by event plus margins (for spawned non-VPS timers),
   time_t StopTimeEvent(void) const; ///< or by the user (for normal timers)
   void SetId(int Id);

Display More

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

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

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

Participate now!

Users Viewing This Thread

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

Participate now!

Users Viewing This Thread

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