[Bug] VPS Recording not starting as long as another recording (with lower priority) is running
Hi,
I created two timers:
5:S19.2E-1-1101-28106:2011-02-26:1330:1500:50:99:Das Traumhotel - Afrika: 9:S19.2E-1-1079-28006:2011-02-26:1300:1500:10:99:Wintersport:
The second timer was recorded for the complete time. The first Timer was ignored, in spite of the higher priority. This is related to VPS: A VPS timer seems to be ignored as long as other recorings block the devices. In this logic, the priority of the recoring is ignored.
Note: For this test, I started VDR with --device=0 so only one device is used. I used no patch (plain 1.7.16) and only one plugin (dvbsddevice).
Regards, Markus
On 26.02.2011 15:24, Markus Ehrnsperger wrote:
Hi,
I created two timers:
5:S19.2E-1-1101-28106:2011-02-26:1330:1500:50:99:Das Traumhotel - Afrika: 9:S19.2E-1-1079-28006:2011-02-26:1300:1500:10:99:Wintersport:
The second timer was recorded for the complete time. The first Timer was ignored, in spite of the higher priority. This is related to VPS: A VPS timer seems to be ignored as long as other recorings block the devices. In this logic, the priority of the recoring is ignored.
Note: For this test, I started VDR with --device=0 so only one device is used. I used no patch (plain 1.7.16) and only one plugin (dvbsddevice).
The problem is that the VPS code in vdr.c avoids devices that are currently recording. And since this is a rather complex area, I'm not sure if it's too good an idea to change this ;-)
If you feel like it, you may want to take a look at the code under
// Find a device that provides the required transponder:
in vdr.c. Maybe you can come up with a better solution...
Klaus
Hi,
On Sun, 06 Mar 2011 17:15:44 +0100, Klaus Schmidinger wrote
The problem is that the VPS code in vdr.c avoids devices that are currently recording. And since this is a rather complex area, I'm not sure if it's too good an idea to change this ;-)
If you feel like it, you may want to take a look at the code under
// Find a device that provides the required transponder:
in vdr.c. Maybe you can come up with a better solution...
Unless I've missed something, that code does not only ignore priorities but also the availability of CAMs. How about using cDevice::GetDevice(const cChannel*, int, bool) to find out which device will do the job? After all that's what cRecordControls::Start(...) uses later when looking for the device to actually start recording from.
Streamdev-server already uses this method for quite a while to find out if a device is available. The only change required in cDevice::GetDevice would be that it needs to become a query only method again like it was before VDR 1.5.0. Currently it may detach receivers of the device it returns. Adding a "query only" flag to the method should do. Streamdev currently includes a copy of cDevice::GetDevice without the detach receivers part to get that "query only" behaviour. Would be happy if I could get rid of that.
OT but related: Any chance to see Udo Richter's patch related to proper priorities on the transfer mode receiver device in VDR? This patch eliminates some more inconsistencies related to priorities. References: http://linuxtv.org/pipermail/vdr/2010-July/023240.html http://projects.vdr-developer.org/issues/10#note-10
Regards, Frank
On 03/07/11 13:23, Frank Schmirler wrote:
Hi,
On Sun, 06 Mar 2011 17:15:44 +0100, Klaus Schmidinger wrote
The problem is that the VPS code in vdr.c avoids devices that are currently recording. And since this is a rather complex area, I'm not sure if it's too good an idea to change this ;-)
If you feel like it, you may want to take a look at the code under
// Find a device that provides the required transponder:
in vdr.c. Maybe you can come up with a better solution...
Unless I've missed something, that code does not only ignore priorities but also the availability of CAMs.
We only need the EIT data here, which is not encrypted. So it's sufficient to find a device that provides the raw transponder.
Klaus
On Mon, 07 Mar 2011 13:33:47 +0100, Klaus Schmidinger wrote
On 03/07/11 13:23, Frank Schmirler wrote:
Hi,
On Sun, 06 Mar 2011 17:15:44 +0100, Klaus Schmidinger wrote
The problem is that the VPS code in vdr.c avoids devices that are currently recording. And since this is a rather complex area, I'm not sure if it's too good an idea to change this ;-)
If you feel like it, you may want to take a look at the code under
// Find a device that provides the required transponder:
in vdr.c. Maybe you can come up with a better solution...
Unless I've missed something, that code does not only ignore priorities but also the availability of CAMs.
We only need the EIT data here, which is not encrypted. So it's sufficient to find a device that provides the raw transponder.
Ah, I see. I ignored the fact, that at the moment this piece of code is only looking for a way to see the VPS start flag for the timer. Still the GetDevice call (or something alike) would become necessary when considering to interrupt a recording with lower priority. The low priority recording shouldn't be interrupted if the VPS recording cannot start later as e.g. the CAM is in use by a higher priority recording.
Regards, Frank
On 03/07/11 14:13, Frank Schmirler wrote:
On Mon, 07 Mar 2011 13:33:47 +0100, Klaus Schmidinger wrote
On 03/07/11 13:23, Frank Schmirler wrote:
Hi,
On Sun, 06 Mar 2011 17:15:44 +0100, Klaus Schmidinger wrote
The problem is that the VPS code in vdr.c avoids devices that are currently recording. And since this is a rather complex area, I'm not sure if it's too good an idea to change this ;-)
If you feel like it, you may want to take a look at the code under
// Find a device that provides the required transponder:
in vdr.c. Maybe you can come up with a better solution...
Unless I've missed something, that code does not only ignore priorities but also the availability of CAMs.
We only need the EIT data here, which is not encrypted. So it's sufficient to find a device that provides the raw transponder.
Ah, I see. I ignored the fact, that at the moment this piece of code is only looking for a way to see the VPS start flag for the timer. Still the GetDevice call (or something alike) would become necessary when considering to interrupt a recording with lower priority. The low priority recording shouldn't be interrupted if the VPS recording cannot start later as e.g. the CAM is in use by a higher priority recording.
Looks like this is beginning to become "rocket science" again ;-)
Klaus
2011/3/7 Klaus Schmidinger Klaus.Schmidinger@tvdr.de:
On 03/07/11 14:13, Frank Schmirler wrote:
On Mon, 07 Mar 2011 13:33:47 +0100, Klaus Schmidinger wrote
On 03/07/11 13:23, Frank Schmirler wrote:
Hi,
On Sun, 06 Mar 2011 17:15:44 +0100, Klaus Schmidinger wrote
The problem is that the VPS code in vdr.c avoids devices that are currently recording. And since this is a rather complex area, I'm not sure if it's too good an idea to change this ;-)
If you feel like it, you may want to take a look at the code under
// Find a device that provides the required transponder:
in vdr.c. Maybe you can come up with a better solution...
Unless I've missed something, that code does not only ignore priorities but also the availability of CAMs.
We only need the EIT data here, which is not encrypted. So it's sufficient to find a device that provides the raw transponder.
Ah, I see. I ignored the fact, that at the moment this piece of code is only looking for a way to see the VPS start flag for the timer. Still the GetDevice call (or something alike) would become necessary when considering to interrupt a recording with lower priority. The low priority recording shouldn't be interrupted if the VPS recording cannot start later as e.g. the CAM is in use by a higher priority recording.
Looks like this is beginning to become "rocket science" again ;-)
It allready is rocket science right now, ignoring the fact doesn't make it go away ;) At least thats my impression.
2011/3/7 Steffen Barszus steffenbpunkt@googlemail.com:
2011/3/7 Klaus Schmidinger Klaus.Schmidinger@tvdr.de:
On 03/07/11 14:13, Frank Schmirler wrote:
On Mon, 07 Mar 2011 13:33:47 +0100, Klaus Schmidinger wrote
On 03/07/11 13:23, Frank Schmirler wrote:
Hi,
On Sun, 06 Mar 2011 17:15:44 +0100, Klaus Schmidinger wrote
The problem is that the VPS code in vdr.c avoids devices that are currently recording. And since this is a rather complex area, I'm not sure if it's too good an idea to change this ;-)
If you feel like it, you may want to take a look at the code under
// Find a device that provides the required transponder:
in vdr.c. Maybe you can come up with a better solution...
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
On 07.03.2011 19:56, Markus Ehrnsperger wrote:
2011/3/7 Steffen Barszus steffenbpunkt@googlemail.com:
2011/3/7 Klaus Schmidinger Klaus.Schmidinger@tvdr.de:
On 03/07/11 14:13, Frank Schmirler wrote:
On Mon, 07 Mar 2011 13:33:47 +0100, Klaus Schmidinger wrote
On 03/07/11 13:23, Frank Schmirler wrote:
Hi,
On Sun, 06 Mar 2011 17:15:44 +0100, Klaus Schmidinger wrote > The problem is that the VPS code in vdr.c avoids devices that are > currently recording. And since this is a rather complex area, > I'm not sure if it's too good an idea to change this ;-) > > If you feel like it, you may want to take a look at the code under > > // Find a device that provides the required transponder: > > in vdr.c. Maybe you can come up with a better solution...
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 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.
- Markus
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.
- Markus
Second try, this time with the patch attached (hopefully)
On 14.03.2011 23:05, Markus Ehrnsperger wrote:
2011/3/14 Markus Ehrnspergermarkus.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
-
Frank Schmirler -
Klaus Schmidinger -
Markus Ehrnsperger -
Steffen Barszus