VDR prefers my CI DVB device for recordings and blocks it unnecessarily

  Jörn Reder wrote:
> ...
> I'm having problems with VDR's decision of recording devices. The 1.4 
> change log states that budget cards are preferred, unfortunately my 
> budget card has the CI. So when a recording starts and no pay TV channel
> is actually tuned, the CI device is blocked and I can't switch to a pay
> TV channel anymore (whithout stopping the recording).
> 
> Is it possible to tell VDR to prefer my FF card for recordings instead 
> of my CI budget device?

Please try the attached patch.
With this change "avoiding full featured or primary cards" gets
less priority than "using the device with the lowest priority
or the lowest number of CA methods".

Klaus
  

Klaus Schmidinger wrote:
> Jörn Reder wrote:
> 
>> ...
>> I'm having problems with VDR's decision of recording devices. The 1.4
>> change log states that budget cards are preferred, unfortunately my
>> budget card has the CI. So when a recording starts and no pay TV channel
>> is actually tuned, the CI device is blocked and I can't switch to a pay
>> TV channel anymore (whithout stopping the recording).
>>
>> Is it possible to tell VDR to prefer my FF card for recordings instead
>> of my CI budget device?
> 
> 
> Please try the attached patch.
> With this change "avoiding full featured or primary cards" gets
> less priority than "using the device with the lowest priority
> or the lowest number of CA methods".
> 
> Klaus
> 
> 
> ------------------------------------------------------------------------
> 
> --- device.c	2006/07/29 10:03:56	1.134
> +++ device.c	2006/08/06 09:37:21
> @@ -295,10 +295,10 @@
>           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();                                 // avoid devices that are receiving
>           imp <<= 1; imp |= device[i] == ActualDevice();                            // avoid the actual device (in case of Transfer Mode)

Note that the above ActualDevice() returns primary device when transfer
mode is not active, so I guess if the user is for example watching a
recording, this will cause VDR to prefer budget card anyway.

Maybe replace it with cTransferControl::ReceiverDevice(), which returns
NULL when transfer mode is not active?

> -         imp <<= 1; imp |= device[i]->IsPrimaryDevice();                           // avoid the primary device
> -         imp <<= 1; imp |= device[i]->HasDecoder();                                // avoid full featured cards
>           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)
>           imp <<= 8; imp |= min(max(device[i]->ProvidesCa(Channel), 0), 0xFF);      // use the device that provides the lowest number of conditional access methods
> +         imp <<= 1; imp |= device[i]->IsPrimaryDevice();                           // avoid the primary device
> +         imp <<= 1; imp |= device[i]->HasDecoder();                                // avoid full featured cards
>           if (imp < Impact) {
>              // This device has less impact than any previous one, so we take it.
>              Impact = imp;
>
  

Klaus Schmidinger wrote:

> Please try the attached patch.
> With this change "avoiding full featured or primary cards" gets
> less priority than "using the device with the lowest priority
> or the lowest number of CA methods".

Thanks for your patch, I played around with it. The ActualDevice() test
has a very high priority, so if I start a recording on the fly, my CI 
device is still preferred. For testing purposes I commented out the 
ActualDevice() test, then your patch worked for me.

I don't understand the device[i]->ProvidesCa(Channel) test, because it 
checks for the currently requested channel. I dunno any internals (so 
please be patient with me ;), but from reading the source code it looks
that the first if condition in the device loop

  device[i]->ProvidesChannel(Channel, Priority, &ndr)

already checks if the device is basically capable of decoding the 
requested channel, this must include a test for decryption capability 
(if the channel is encrypted), not?. So why another ProvidesCA() test? 
All devices in this if block should pass it anyway.

What about adding a high priority test like hasCAM() (ideally with 
weighting the number of channels the device is able to decrypt) to avoid
blocking a CA device unnecessarily?

Regards,

Joern