Re: [vdr] Regression from a fix in VDR 1.4.1: Needless blocking of CAM DVB cards
Udo Richter wrote: > I've attached a debug patch for impact logging. It dumps the reasons why > VDR used a certain device to the console. (replace printf with isyslog > if you prefer the log files.) > [...] Thanks for this patch, but I don't know when I can test it. I downgraded my production vdr to 1.4, because I had more critical issues with 1.6 regarding pay TV. With vdr 1.6 I often "lost" my CAM card completely being unable to receive encrypted channels at all, even when no recording was started. I have no idea which conditions led to this. A vdr restart solved it temporarily, but programming pay TV timers was a lottery and the "woman acceptance factor" fell down to 0.0 (but my AF as well... :) So I need to compile a vanilla 1.6 to run besides my production 1.4. Probably I find some time to do this around x-mas. I'll post the results. Regards, Jörn -- .''`. Jörn Reder : :' : http://www.exit1.org/ `. `' `-Debian GNU/Linux -- The power of freedom pgp53ib9i6boq.pgp Description: PGP signature ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Regression from a fix in VDR 1.4.1: Needless blocking of CAM DVB cards
On 01.12.2008 16:02, Jörn Reder wrote: Jörn Reder wrote: With vdr 1.4 this worked perfectly, now with 1.6 VDR always prefers my Budget CI card for recordings so I can't view any Pay TV when a recording is active. The rules that were added with 1.4.1-4 are still present, so they probably got over-ruled by something else. I can reproduce it this way: - watching a non pay TV channel (e.g. ARD) - manually start a recording on it (go to menu, hit RED button) - now switching to a pay TV channel is impossible I've attached a debug patch for impact logging. It dumps the reasons why VDR used a certain device to the console. (replace printf with isyslog if you prefer the log files.) Output looks like this: Impact: LiDeReTrPriPrcNdPrCiDeDc Dev 0.00: 0 0 0 0 62 63 1 1 1 1 0 Dev 1.00: 0 0 0 0 62 63 0 0 1 0 0 Device 1.00 wins The first difference decides, lower value wins. In this case, the second device wins because its Nd is 0. Thats the 'needs detach receivers' rule. Run the above test case and post the corresponding output here. Cheers, Udo --- device.c.orig 2008-12-21 15:46:20.0 +0100 +++ device.c2008-12-21 15:51:44.0 +0100 @@ -384,6 +384,8 @@ cCamSlot *s = NULL; uint32_t Impact = 0x; // we're looking for a device with the least impact + printf("Impact: LiDeReTrPriPrcNdPrCiDeDc\n"); + int besti=0, bestj=0; for (int j = 0; j < NumCamSlots || !NumUsableSlots; j++) { if (NumUsableSlots && SlotPriority[j] > MAXPRIORITY) continue; // there is no CAM available in this slot @@ -419,10 +421,29 @@ imp <<= 1; imp |= NumUsableSlots ? 0 : device[i]->HasCi(); // avoid cards with Common Interface for FTA channels imp <<= 1; imp |= device[i]->HasDecoder(); // avoid full featured cards imp <<= 1; imp |= NumUsableSlots ? !ChannelCamRelations.CamDecrypt(Channel->GetChannelID(), j + 1) : 0; // prefer CAMs that are known to decrypt this channel + + #define bitextract(u, bit, len) (((u) >> (bit)) & ((1 << (len)) - 1)) + printf("Dev %2i.%02i: %i %i %i %i %02x %02x %i %i %i %i %i\n", +i, +j, +bitextract(imp, 24, 1), +bitextract(imp, 23, 1), +bitextract(imp, 22, 1), +bitextract(imp, 21, 1), +bitextract(imp, 13, 8), +bitextract(imp, 5, 8), +bitextract(imp, 4, 1), +bitextract(imp, 3, 1), +bitextract(imp, 2, 1), +bitextract(imp, 1, 1), +bitextract(imp, 0, 1)); + if (imp < Impact) { // This device has less impact than any previous one, so we take it. Impact = imp; d = device[i]; +besti=i; +bestj=j; NeedsDetachReceivers = ndr; if (NumUsableSlots) s = CamSlots.Get(j); @@ -433,6 +454,7 @@ break; // no CAM necessary, so just one loop over the devices } if (d) { + printf("Device %2i.%02i wins\n", besti,bestj); if (NeedsDetachReceivers) d->DetachAllReceivers(); if (s) { ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Regression from a fix in VDR 1.4.1: Needless blocking of CAM DVB cards
Udo Richter wrote: > Jörn Reder wrote: > > With vdr 1.4 this worked perfectly, now with 1.6 VDR always prefers my > > Budget CI card for recordings so I can't view any Pay TV when a > > recording is active. > > The rules that were added with 1.4.1-4 are still present, so they > probably got over-ruled by something else. Ok - thanks for checking this that quickly ;) > Can you confirm that this problem occurs without loading any plugins? At > least osdteletext is known to cause channels to be blocked. Yes. I just tested it with a plain VDR without any plugins loaded. I can reproduce it this way: - watching a non pay TV channel (e.g. ARD) - manually start a recording on it (go to menu, hit RED button) - now switching to a pay TV channel is impossible In that case with vdr 1.4 I could see that vdr switched the card when starting the non pay TV recording (short black screen). Now the live viewing isn't interrupted, which is nice, but keeping the CAM card free is more important in my opinion ;) Thanks, Jörn -- .''`. Jörn Reder <[EMAIL PROTECTED]> : :' : http://www.exit1.org/ `. `' `-Debian GNU/Linux -- The power of freedom pgpkv0qBxg37d.pgp Description: PGP signature ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Regression from a fix in VDR 1.4.1: Needless blocking of CAM DVB cards
Jörn Reder wrote: > With vdr 1.4 this worked perfectly, now with 1.6 VDR always prefers my > Budget CI card for recordings so I can't view any Pay TV when a > recording is active. The rules that were added with 1.4.1-4 are still present, so they probably got over-ruled by something else. Can you confirm that this problem occurs without loading any plugins? At least osdteletext is known to cause channels to be blocked. Cheers, Udo ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr