Re: [vdr] [Bug] VPS Recording not starting as long as another recording (with lower priority) is running
2011/3/7 Steffen Barszus : > 2011/3/7 Klaus Schmidinger : >> 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 ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [Bug] VPS Recording not starting as long as another recording (with lower priority) is running
2011/3/7 Klaus Schmidinger : > 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. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [Bug] VPS Recording not starting as long as another recording (with lower priority) is running
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 ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [Bug] VPS Recording not starting as long as another recording (with lower priority) is running
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 ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [Bug] VPS Recording not starting as long as another recording (with lower priority) is running
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 ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [Bug] VPS Recording not starting as long as another recording (with lower priority) is running
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 ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
