Hiho,
I'm a happy VDR user for years and recently installed a common interface to receive pay TV.
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?
Regards,
Joern
On Sat, Aug 05, 2006 at 02:52:30PM +0200, Jörn Reder wrote:
Hiho,
I'm a happy VDR user for years and recently installed a common interface to receive pay TV.
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?
yep, just adjust the priority calculations in device.c so that the full featured card wins over the budget one (or even better, add a new check for CI ...)
imp <<= 1; imp |= device[i]->HasDecoder();
HTH, Herbert
Regards,
Joern
-- .''`. Jörn Reder joern@zyn.de : :' : http://www.exit1.org/ http://www.zyn.de/ `. `' `- Debian GNU/Linux -- The power of freedom
vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
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
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 wrote:
Yes, the ActualDevice() test has to be modified, too. Please try my attached patch (it is against 1.4.1-3).
Thanks, works like a charm.
Regards,
Joern