[vdr] [ANNOUNCE] VDR developer version 1.7.24

Klaus Schmidinger Klaus.Schmidinger at tvdr.de
Fri Feb 24 17:23:18 CET 2012


On 24.02.2012 15:37, Frank Schmirler wrote:
> Hi,
>
> On Sun, 19 Feb 2012 14:54:48 +0100, Klaus Schmidinger wrote
>> - Fixed handling the  PrimaryLimit when requesting a device for live viewing
>>     (reported by Uwe Scheffler).
>
> Refers to the following change in device.c:
> -          if (device[i]->ProvidesChannel(Channel, Priority,&ndr)) { // this
> device is basicly able to do the job
> +          if (device[i]->ProvidesChannel(Channel, (LiveView&&
> device[i]->IsPrimaryDevice()) ? Setup.PrimaryLimit : Priority,&ndr)) { //
> this device is basicly able to do the job
>
> With this modification the GetDevice parameter Priority becomes meaningless in
> case LiveView is true. This should at least be mentioned in the function's
> documentation in device.h.
>
> Anyway, I think a better way to fix the problem would be to change the
> priority parameter of the GetDevice calls involved from "GetDevice(channel, 0,
> true)" to "GetDevice(channel, Setup.PrimaryLimit, true)". There are two calls
> in device.c and one call in menu.c.
>
> Imagine a two card system with PrimaryLimit 20, a high priority recording
> (e.g. 50) running on the PrimaryDevice and a low priority recording (e.g. 10)
> on the second card. With 1.7.24 live TV would not interrupt the low priority
> recording, as PrimaryLimit priority is only used when checking the
> PrimaryDevice, but priority 0 is used when checking the second card.
>
> The way 1.7.24 resolves the problem is not wrong as according to MANUAL
> PrimaryLimit is not meant to affect transfer mode. IMHO it should, as the
> intention of this parameter is prefering LiveTV to low priority recordings.
> I'm still hoping to get a more priority driven device selection.

IIRC that whole "Primary Limit" thing was introduced because in the beginning
the full featured DVB cards were unable to record and play at the same time.
So it could happen that a timer occupied the primary device and left the
user with a black screen. Since the old FF cards have been given the ability
to do simultaneous recording and replay a long time ago, and the new TT S2-6400
has been able to do this from the very start, I'd rather prefer to do away with
the "Primary Limit" altogether - to make things simpler instead of more complex ;-)

So, is there anybody who would *really* miss the "Primary Limit" if it were gone?

> BTW: Any update on this related issue:
> http://www.mail-archive.com/vdr@linuxtv.org/msg14166.html?

I assume you are referring to

   http://projects.vdr-developer.org/attachments/355/vdr-1.7.12-detachreceiver-4.diff

Well, I don't like the idea of introducing yet another parameter ("volatile") here.
The "priority" should be sufficient to solve this. So if you can suggest a solution
that works solely with priorities, I might take a look ;-)

Klaus



More information about the vdr mailing list