[vdr] VDR prefers my CI DVB device for recordings and blocks
anssi.hannula at gmail.com
Mon Aug 7 23:51:39 CEST 2006
Jörn Reder wrote:
> 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.
Yes, the ActualDevice() test has to be modified, too. Please try my
attached patch (it is against 1.4.1-3).
> 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.
The ProvidesCa() is done because it also returns the number of cam
methods the device offers. Therefore we prefer a device that provides as
few cam methods as possible.
> 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?
The attached patch will do fine (though it will not weigh the number of
channels, but number of encryptions).
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 1755 bytes
Desc: not available
Url : http://www.linuxtv.org/pipermail/vdr/attachments/20060808/92947a37/vdr-1.4.1-3-getdevice.bin
More information about the vdr