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). -- Anssi Hannula -------------- next part -------------- A non-text attachment was scrubbed... Name: vdr-1.4.1-3-getdevice.diff Type: text/x-patch Size: 1755 bytes Desc: not available Url : http://www.linuxtv.org/pipermail/vdr/attachments/20060808/92947a37/vdr-1.4.1-3-getdevice.bin
