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

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

 



Udo Richter schrieb:

> C.Y.M wrote:
>
>> The problem I am experiencing with this starttime patch has to do 
>> with a new
>> function in the text2skin plugin that was introduced by Enigma.
>>
>> Enigma will list the upcoming timers in the main menu and thats what 
>> sends vdr
>> into a lockup.
>
>
> I *think* I found the reason in this code piece from status.c, 
> cText2SkinStatus::UpdateEvents():
>
> if (!dummy.IsSingleEvent()) // add 4 additional rep. timer
> {
>     do
>     {
>         dummy.Skip();
>         dummy.Matches(); // Refresh start- and end-time
>     } while (!dummy.DayMatches(dummy.Day()));
> }
>
> With my patch, StartTime() no longer points to days that are no 
> recording days, and as a consequence, Skip() will correctly skip one 
> week forward each time, to the day after the next recording. The above 
> loop seems to expect Skip() to jump in 1-day steps and expects the 
> timer to match the day mask finally. Since Skip() jumps to the day 
> after the next timer, the day mask never matches.
>
> The loop can now probably be avoided completely, since Skip() and 
> StartTime() will deliver all future timers directly.

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?

Bye,
Andreas Brugger



[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