Hi list, Referring to http://www.vdr-portal.de/board/thread.php?postid=468928#post468928 , here's a patch that fixes calculation of startTime in case that they (1) are weekly timers (2) have a start day set (3) have next scheduled recording more than 7 days in the future In this case, the timer will be sorted in the timer list at the start day, even if the start day doesn't match the weekday mask. (this can be down to two days from now for a timer that will record in 8 days) Since the fix is at a rather sensitive code piece, it could use some review and testing. The change only affects repeated timers with start date set. The fix does two things: First, the scan loop for matching timer events is shifted from now (or whatever t is) to the scheduled start day. That way the loop should always find a match. Second, the startTime safety catchup is changed to a time that is really one week in the future - 'day' may be earlier. However, I don't think that this catch is triggered at all any more. Cheers, Udo -------------- next part -------------- --- vdr-1.4.0-orig/timers.c 2006-05-20 18:50:49.000000000 +0200 +++ vdr-1.4.0/timers.c 2006-05-20 18:50:54.000000000 +0200 @@ -347,7 +347,7 @@ } else { for (int i = -1; i <= 7; i++) { - time_t t0 = IncDay(t, i); + time_t t0 = IncDay(day ? max(day, t) : t, i); if (DayMatches(t0)) { time_t a = SetTime(t0, begin); time_t b = a + length; @@ -359,7 +359,7 @@ } } if (!startTime) - startTime = day; // just to have something that's more than a week in the future + startTime = IncDay(t, 7); // just to have something that's more than a week in the future else if (!Directly && (t > startTime || t > day + SECSINDAY + 3600)) // +3600 in case of DST change day = 0; }
