[Bug] VPS Recording not starting as long as another recording (with lower priority) is running

Message ID 4F4A5D45.2080305@tvdr.de
State New
Headers

Commit Message

Klaus Schmidinger Feb. 26, 2012, 4:26 p.m. UTC
  On 14.03.2011 23:05, Markus Ehrnsperger wrote:
> 2011/3/14 Markus Ehrnsperger<markus.ehrnsperger@googlemail.com>:
>>>> Hi,
>>>>
>>>> I have a suggestion: Treat the VPS margin the same way as the time a
>>>> non VPS timer will start before the EPG event starts. Example:
>>>>
>>>> Tagesschau, starts at 8:00 PM.
>>>>
>>>> If I don't use VPS, I will create a timer at 7:58 PM (in case the news
>>>> start slightly before 8)
>>>> If I use VPS, I will create a timer at 8:00 PM. The VPS margin is 2
>>>> minutes (in this example).
>>>>
>>>>
>>>> If I don't use VPS, another recording (with lower priority) will be
>>>> stopped at 7.58 PM. The timer will start recording.
>>>> If I use VPS, another recording (with lower priority) will be stopped
>>>> at 7.58 PM (my suggestion). The next two minutes, the device will be
>>>> used for VPS checking only. The recording will start at 8:00 PM.
>>>>
>>>> Of course, this might look like wasting a device for two minutes only
>>>> to check the VPS. On the other side, not using VPS is even worse: I
>>>> will waste the device and disk space. So, using VPS is still better.
>>>> And, the timer with lower priority has lower priority by purpose. So,
>>>> I want it to be interrupted.
>>>>
>>>> Summary:
>>>> I suggest to use GetDevice as soon as the timer is within the VPS margin.
>>>> This has the following advantages:
>>>> - Easy to implement
>>>> - Easy to understand for users, and expected behavior: The timer with
>>>> higher priority has higher priority :) .
>>>> - No rocket science
>>>>
>>>> I admit, it has some disadvantages. But, from my point of view, these
>>>> are minor compared to the advantages. At the moment, I can use VPS
>>>> only with care as I might miss a recording with very high priority.
>>>>
>>>> Markus
>>>
>>> Please provide a (tested) patch that implements this.
>>>
>>> Klaus
>>>
>> Hi,
>>
>> I attach a simple patch. I tried it out and it works for me. Any
>> comments are very welkome.

Sorry I didn't get to this earlier...

I'd rather like to give the attached method a try.
It modifies the code that actually checks whether a timer matches,
and now takes into account whether the "present" event has been seen
within a certain time. If it hasn't, the timer behaves like a normal
timer and starts at the start time of the event (provided its priority
is high enough).

Klaus
  

Patch

===================================================================
RCS file: ./RCS/timers.c
retrieving revision 2.7
diff -u -b -r2.7 ./timers.c
--- ./timers.c	2012/02/20 15:51:55	2.7
+++ ./timers.c	2012/02/26 16:09:30
@@ -433,8 +433,12 @@ 
         if (Margin || !Directly) {
            startTime = event->StartTime();
            stopTime = event->EndTime();
-           if (!Margin)
+           if (!Margin) { // this is an actual check
+              if (event->Schedule()->PresentSeenWithin(Setup.VpsMargin / 2)) // VPS control can only work with up-to-date events...
               return event->IsRunning(true);
+              else
+                 return startTime <= t && t < stopTime; // ...otherwise we fall back to normal timer handling
+              }
            }
         }
      return startTime <= t + Margin && t < stopTime; // must stop *before* stopTime to allow adjacent timers