[vdr] Bug? Missing next timer event

Udo Richter udo_richter at gmx.de
Wed Aug 2 17:24:49 CEST 2006


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




More information about the vdr mailing list