Hi list,
I just noticed a serious issue with a missed timer event. After a daily timer, VDR did an automatic shutdown, but not for the next day to record the same timer again, but for the next following timer event!
I never noticed this before, so my guess is that this issue is somehow quite sensitive to bad timing. And: This shutdown was done by the original 1.4.1-2 code, not using any of the experimental shutdown patches since then.
I followed the source code for such situations, and thats what should happen:
cRecordControls::Process(t) and cRecordControl::Process(t) do the timer checks periodically by calling cTimer::Matches(t). As soon as cTimer::Matches(t) returns false, the recording is stopped.
Some minutes later, the next timer is searched by cTimers::GetNextActiveTimer(), returning the closest (oldest) start time timer that has a stop time that is not yet passed.
*speculation* Could the timer still be on the stopped time event? That way GetNextActiveTimer would ignore it. cTimer::StopTime() has a cache that has to be refreshed by calling cTimer::Matches(t). Could it be that Matches was not called after the event and before the shutdown?
There's one call to Matches for sure: The one from cRecordControl::Process, that returned false and stopped the timer. But: If Matches(t) was called /exactly at/ t=StopTime, then Matches(t) returns false, but the cached StartTime/StopTime refer to the last timer hit, not the next one! If there was no call to Matches() after that and before the shutdown, then the timer may be skipped!
Well, thats speculative. There should have been a call to Matches before from the TIMERCHECKDELTA loop in vdr.c. But it may be a good idea to call Matches() from within GetNextActiveTimer(), just to make sure.
Cheers,
Udo