[Patch] Fix calculating starttime of repeated timers with start date

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Andreas Brugger wrote:
> Shouldn't Skip() actually skip to the next day, where the timer should 
> record and not to the day after?
> I know the VDR's Skip() does not, but I think a "corrected" version 
> should or am I missing something here?

Skip() sets the start day to the following day after StartTime(). Until 
now this was fine for VDR, because Skip() is only used for timers that 
have no start day set. For timers that have a start day, Skip() did 
weired things because of the sometimes wrong StartTime() for these timers.

The original patch did not attempt to fix Skip(), it just fixes the 
wrong calculation of StartTime(). Skip() could be fixed by this 
additional patch: (untested!)
--- timers.c.orig	2006-05-20 18:50:49.000000000 +0200
+++ timers.c	2006-05-22 21:22:37.364563392 +0200
@@ -560,6 +560,7 @@
  void cTimer::Skip(void)
  {
    day = IncDay(SetTime(StartTime(), 0), 1);
+  day = SetTime(StartTime(), 0);
    SetEvent(NULL);
  }


However, with the original patch you can be quite sure that after Skip() 
the StartTime() will match the day mask, even if the start day does not. 
(and you can always set the start day to a non-recording day manually)

A variant of the problematic loop in Enigma may be to Skip() until 
StartTime() instead of Day() matches the day mask - this should be 
instantly true with the patch, and will be true after some loops without 
the patch. (StartTime() however will then be falsely at midnight.) And 
add a failsafe that terminates after some 100 loops. ;)

Cheers,

Udo



[Index of Archives]     [Linux Media]     [Asterisk]     [DCCP]     [Netdev]     [Xorg]     [Util Linux NG]     [Xfree86]     [Big List of Linux Books]     [Fedora Users]     [Fedora Women]     [ALSA Devel]     [Linux USB]

  Powered by Linux