[vdr] Re: VDR prefers my CI DVB device for recordings and blocks
anssi.hannula at gmail.com
Sat Aug 26 16:01:09 CEST 2006
Anssi Hannula wrote:
> Klaus Schmidinger wrote:
>> Anssi Hannula wrote:
>>> diff -Nurp -x '*~' vdr-1.4.1-5/device.c vdr-1.4.1-5-mod/device.c
>>> --- vdr-1.4.1-5/device.c 2006-08-20 21:59:20.000000000 +0300
>>> +++ vdr-1.4.1-5-mod/device.c 2006-08-23 18:41:26.000000000 +0300
>>> @@ -292,7 +292,7 @@ cDevice *cDevice::GetDevice(const cChann
>>> // to their individual severity, where the one listed first
>>> will make the most
>>> // difference, because it results in the most significant
>>> bit of the result.
>>> uint imp = 0;
>>> - imp <<= 1; imp |= !device[i]->Receiving(true) ||
>>> ndr; // use receiving devices if we don't need to
>>> detach existing receivers
>>> + imp <<= 1; imp |= !device[i]->Receiving() && device[i] !=
>>> cTransferControl::ReceiverDevice() || ndr; // use receiving devices if
>>> we don't need to detach existing receivers
>>> imp <<= 1; imp |=
>>> device[i]->Receiving(); // avoid
>>> devices that are receiving
>>> imp <<= 1; imp |= device[i] ==
>>> cTransferControl::ReceiverDevice(); // avoid the Transfer Mode
>>> receiver device
>>> imp <<= 8; imp |= min(max(device[i]->Priority() +
>>> MAXPRIORITY, 0), 0xFF); // use the device with the lowest priority
>>> (+MAXPRIORITY to assure that values -99..99 can be used)
>> Wouldn't this also avoid a non-primary device if the transfer mode
>> is coming from there? I don't think that would be good...
> I don't understand what you mean. It just modifies the algorithm to
> prefer receiving devices on the same transponder that have priority>=0
> receivers or transfer mode receivers. Before the patch it would prefer
> any receiving devices on the same transponder, causing osdteletext
> receiver to make a difference.
> Consider scenario
> - user watches transponder 1 channel 1 through primary FF
> - recording starts on transponder 1 channel 2
> Before this patch:
> - if osdteletext has a receiver on FF, the recording is made via FF
> (Receiving(true) is true), otherwise via budget card
> After this patch:
> - recording is made via budget card (same behaviour as VDR 1.4.1)
> The alternative (more logical) fix would be to prefer transponder-tuned
> primary devices too, so that the recording in above example would be
> made by FF as it is tuned in the same transponder. But this would
> probably not be a good idea (at least without YASO) due to the apparent
> problems with recording via FF.
> However, one possibility is to prefer the FF for recording in this
> situation by default (which would leave the budget card free), and also
> in the original situation (in which the budget has CAM), and have a
> setup option for Avoiding primary device for recording at all cost.
Attached is a patch which has this approach.
So after *this* patch the above quoted scenario would continue like this
- recording is made via budget card (same behaviour as VDR 1.4.1) if
AvoidPrimaryDevice is set
- recording is made via FF card (leaving budget free) if
AvoidPrimaryDevice is not set.
Also if AvoidPrimaryDevice is set, budget with CAM would be preferred
over non-CAM FF for recording FTA channels in the original situation.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 3372 bytes
Desc: not available
Url : http://www.linuxtv.org/pipermail/vdr/attachments/20060826/20b9bafe/vdr-1.4.1-5-getdevice-alt.bin
More information about the vdr