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

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

 



On 14.03.2011 23:05, Markus Ehrnsperger wrote:
2011/3/14 Markus Ehrnsperger<markus.ehrnsperger@xxxxxxxxxxxxxx>:
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
===================================================================
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
_______________________________________________
vdr mailing list
vdr@xxxxxxxxxxx
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

[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