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).