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
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.
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
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.
vdr mailing list