Re: [vdr] [ANNOUNCE] VDR developer version 1.5.0
Heikki Manninen wrote: > Klaus Schmidinger wrote: >> Heikki Manninen wrote: >>> On su, 2007-01-14 at 14:48 +0100, Klaus Schmidinger wrote: >>> Your CAM doesn't respond to the QUERY that VDR sends to it. So VDR can't ask the CAM whether it is able to decrypt a certain channel (in addition to others it is already decrypting). So it's a hard-/firmware restriction of your CAM. The only CAM I have here that actually can decrypt more than one channel is the Alphacrypt with firmware revision 3.09. >>> Conax 4.00e is able to decrypt 2-3 channels at the same time. Although >>> when used with VDR 1.5.0 it is not. Also when using previous versions of >> >> If the CAM doesn't respond to a QUERY, then how is VDR supposed to >> know whether it can decrypt more than one channel at a time? > > Didn't mean that it is supposed to. Just informed you to let you (and > others) now that sometimes it's possible :) > >>> VDR you have to fake fixed receiver number in the channels.conf for this >>> to be possible - if you put in B00 it doesn't work anymore :) It's >>> sometimes a bit unrealiable but works. >> >> VDR 1.4 used the FIRST/MORE/LAST method to send multiple CaPmts. >> Since some CAMs apparently don't handle this correctly, I changed >> that to the simpler ADD/UPDATE method, which should be supported >> by any CAM that can decrypt more than one channel. >> >> Can you please check if there is a newer firmware for the Conax CAM >> and maybe try that? > > Hmm.. have to try. Although I'm not aware how to do it. Should it be > able to update from the broadcast signal? That depends on the manufacturer of the CAM. Some do, some don't. The Alphacrypt CAM, for instance, can be updated via satellite, and VDR supports this. Klaus ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.5.0
Klaus Schmidinger wrote: Heikki Manninen wrote: On su, 2007-01-14 at 14:48 +0100, Klaus Schmidinger wrote: Your CAM doesn't respond to the QUERY that VDR sends to it. So VDR can't ask the CAM whether it is able to decrypt a certain channel (in addition to others it is already decrypting). So it's a hard-/firmware restriction of your CAM. The only CAM I have here that actually can decrypt more than one channel is the Alphacrypt with firmware revision 3.09. Conax 4.00e is able to decrypt 2-3 channels at the same time. Although when used with VDR 1.5.0 it is not. Also when using previous versions of If the CAM doesn't respond to a QUERY, then how is VDR supposed to know whether it can decrypt more than one channel at a time? Didn't mean that it is supposed to. Just informed you to let you (and others) now that sometimes it's possible :) VDR you have to fake fixed receiver number in the channels.conf for this to be possible - if you put in B00 it doesn't work anymore :) It's sometimes a bit unrealiable but works. VDR 1.4 used the FIRST/MORE/LAST method to send multiple CaPmts. Since some CAMs apparently don't handle this correctly, I changed that to the simpler ADD/UPDATE method, which should be supported by any CAM that can decrypt more than one channel. Can you please check if there is a newer firmware for the Conax CAM and maybe try that? Hmm.. have to try. Although I'm not aware how to do it. Should it be able to update from the broadcast signal? -- Heikki M ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.5.0
Klaus Schmidinger wrote: > Heikki Manninen wrote: > >>On su, 2007-01-14 at 14:48 +0100, Klaus Schmidinger wrote: >> >> >>>Your CAM doesn't respond to the QUERY that VDR sends to it. >>>So VDR can't ask the CAM whether it is able to decrypt a certain >>>channel (in addition to others it is already decrypting). >>>So it's a hard-/firmware restriction of your CAM. >>> >>>The only CAM I have here that actually can decrypt more than one >>>channel is the Alphacrypt with firmware revision 3.09. >> >>Conax 4.00e is able to decrypt 2-3 channels at the same time. Although >>when used with VDR 1.5.0 it is not. Also when using previous versions of > > If the CAM doesn't respond to a QUERY, then how is VDR supposed to > know whether it can decrypt more than one channel at a time? I think i can say with resonable confidence that most VDR-Systems don't change at a regular basis, but stay unchanged (more or less) for sometimes years(*). So why not make a "probe capabilities" function (where you could also probe "unsafe" things, with a bit of user interaction(*2)) and then store the information away in a config-file. The next time the system has significant changes you can probe again. *: My first VDR-machine is for e.g. practically unchanged (hardware-wise) since i build it sometime near end of 2000(!). *2: Ever installed Windows? I've seen: "The screen may go blank and the computer can freeze", or something in the same sense. Bis denn -- Real Programmers consider "what you see is what you get" to be just as bad a concept in Text Editors as it is in women. No, the Real Programmer wants a "you asked for it, you got it" text editor -- complicated, cryptic, powerful, unforgiving, dangerous. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.5.0
Heikki Manninen wrote: > On su, 2007-01-14 at 14:48 +0100, Klaus Schmidinger wrote: > >> Your CAM doesn't respond to the QUERY that VDR sends to it. >> So VDR can't ask the CAM whether it is able to decrypt a certain >> channel (in addition to others it is already decrypting). >> So it's a hard-/firmware restriction of your CAM. >> >> The only CAM I have here that actually can decrypt more than one >> channel is the Alphacrypt with firmware revision 3.09. > > Conax 4.00e is able to decrypt 2-3 channels at the same time. Although > when used with VDR 1.5.0 it is not. Also when using previous versions of If the CAM doesn't respond to a QUERY, then how is VDR supposed to know whether it can decrypt more than one channel at a time? > VDR you have to fake fixed receiver number in the channels.conf for this > to be possible - if you put in B00 it doesn't work anymore :) It's > sometimes a bit unrealiable but works. VDR 1.4 used the FIRST/MORE/LAST method to send multiple CaPmts. Since some CAMs apparently don't handle this correctly, I changed that to the simpler ADD/UPDATE method, which should be supported by any CAM that can decrypt more than one channel. Can you please check if there is a newer firmware for the Conax CAM and maybe try that? Klaus ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.5.0
On su, 2007-01-14 at 14:48 +0100, Klaus Schmidinger wrote: > Your CAM doesn't respond to the QUERY that VDR sends to it. > So VDR can't ask the CAM whether it is able to decrypt a certain > channel (in addition to others it is already decrypting). > So it's a hard-/firmware restriction of your CAM. > > The only CAM I have here that actually can decrypt more than one > channel is the Alphacrypt with firmware revision 3.09. Conax 4.00e is able to decrypt 2-3 channels at the same time. Although when used with VDR 1.5.0 it is not. Also when using previous versions of VDR you have to fake fixed receiver number in the channels.conf for this to be possible - if you put in B00 it doesn't work anymore :) It's sometimes a bit unrealiable but works. -- Heikki M ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.5.0
Klaus Schmidinger wrote: Petri Helin wrote: But anyway, now it works, though only for one channel at time as stated in the vdr's log. Is that a hardware specific restriction? Your CAM doesn't respond to the QUERY that VDR sends to it. So VDR can't ask the CAM whether it is able to decrypt a certain channel (in addition to others it is already decrypting). So it's a hard-/firmware restriction of your CAM. The only CAM I have here that actually can decrypt more than one channel is the Alphacrypt with firmware revision 3.09. Is it possible to override the query and just try to decrypt two channels? -Petri ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.5.0
Petri Helin wrote: > Klaus Schmidinger wrote: >> Petri Helin wrote: >>> But anyway, now it works, though only for one channel at time as stated >>> in the vdr's log. Is that a hardware specific restriction? >> >> Your CAM doesn't respond to the QUERY that VDR sends to it. >> So VDR can't ask the CAM whether it is able to decrypt a certain >> channel (in addition to others it is already decrypting). >> So it's a hard-/firmware restriction of your CAM. >> >> The only CAM I have here that actually can decrypt more than one >> channel is the Alphacrypt with firmware revision 3.09. >> > > Is it possible to override the query and just try to decrypt two channels? Just make the function cCamSlot::CanDecrypt() always return 'true'. Klaus ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.5.0
Petri Helin wrote: > Klaus Schmidinger wrote: >... >> Please set the CA parameter of these channels to 0 (FTA) and tune to >> them again. >> VDR should automatically insert the correct CA values then. >> >>> From the HISTORY: >> >> - Ca values in the range 0...F in channels.conf can still be used to >> assign a channel >> to a particular device, but this will no longer work with encrypted >> channels because >> without valid CA ids VDR can't decide which CAM slot to use. >> However, since VDR now >> automatically determines which CAM can decrypt which channel, >> setting fixed >> channel/device relations should no longer be necessary. >> >> >> Klaus >> > > Oh, should have read that HISTORY more carefully, though it still not > clear to me, after reading that part of HISTORY, that i should change > the channels.conf file. Maybe that could be impressed in a way that > would make it clear, even for me? Ok, will do. > But anyway, now it works, though only for one channel at time as stated > in the vdr's log. Is that a hardware specific restriction? Your CAM doesn't respond to the QUERY that VDR sends to it. So VDR can't ask the CAM whether it is able to decrypt a certain channel (in addition to others it is already decrypting). So it's a hard-/firmware restriction of your CAM. The only CAM I have here that actually can decrypt more than one channel is the Alphacrypt with firmware revision 3.09. Greetings Klaus ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.5.0
Klaus Schmidinger wrote: Petri Helin wrote: Klaus Schmidinger wrote: Petri Helin wrote: Klaus Schmidinger wrote: Petri Helin wrote: Klaus Schmidinger wrote: Looks like the CAM is recognized all right. Please enable the lines static bool DumpTPDUDataTransfer = false; static bool DebugProtocol = false; static bool DumpPolls = false; static bool DumpDateTime = false; in ci.c by changing them to 'true' and compile/run VDR again, redirecting stderr into a file, as in ./vdr 2> ci.txt Then send me the resulting output after trying to switch to an encrypted channel. Attached. Everything looks fine, the CaPmt is sent to the CAM and the communication with the CAM is stable. It should work. Can you please do the same with VDR 1.4 and send me the result of that, too? ... Here you are. Ah, now I see the difference: 3: ==> Ca Pmt 4 --> 00 01 A0 2F 01 90 02 00 03 9F 80 32 26 03 01 35 01 00 07 01 09 04 0B 00 E0 68 02 02 06 00 00 04 02 AE 00 00 04 02 AF 00 00 04 02 AC 00 00 04 02 AD 00 00 Slot 1: ==> Ca Pmt (3) 3 3 1: --> 00 01 A0 10 01 90 02 00 03 9F 80 32 07 03 00 00 01 00 01 03 For some reason VDR 1.4.4 sends the CA descriptors in the CaPmt, while VDR 1.5.0 doesn't. Please post the channels.conf entry for the channel you are trying to tune to. Also, just to make sure: are you using plain vanilla VDR 1.5.0 or are there any patches involved? Klaus ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr Here are the channels that VDR 1.5.0 cannot tune to: Canal+ Mix;Telenor:266000:C0M128:C:6900:518:686=nor,687=fin,684=sve,685=dan:581:1:309:0:9:0 Canal+ Film 1;Telenor:266000:C0M128:C:6900:512:650=sve,651=dan,652=nor,653=fin;654=eng:576:1:301:0:9:0 Canal+ Film 2;Telenor:266000:C0M128:C:6900:515:682=nor,683=fin,680=sve,681=dan;679=eng:579:1:308:0:9:0 Canal+ Film 3;Telenor:314000:C0M128:C:6900:518:664=sve,665=dan,666=nor,667=fin;668=eng:577:1:3307:0:19:0 Canal+ HD;Telenor:33:C0M256:C:6900:512:640;641=eng:580:1:3306:0:22:0 Canal+ Sport 1;Telenor:266000:C0M128:C:6900:514:670=fin:577:1:305:0:9:0 Canal+ Sport 2;Telenor:314000:C0M128:C:6900:519:672=sve,673=dan,674=nor,675=fin:578:1:3308:0:19:0 Ah, just as I thought. Please set the CA parameter of these channels to 0 (FTA) and tune to them again. VDR should automatically insert the correct CA values then. From the HISTORY: - Ca values in the range 0...F in channels.conf can still be used to assign a channel to a particular device, but this will no longer work with encrypted channels because without valid CA ids VDR can't decide which CAM slot to use. However, since VDR now automatically determines which CAM can decrypt which channel, setting fixed channel/device relations should no longer be necessary. Klaus Oh, should have read that HISTORY more carefully, though it still not clear to me, after reading that part of HISTORY, that i should change the channels.conf file. Maybe that could be impressed in a way that would make it clear, even for me? But anyway, now it works, though only for one channel at time as stated in the vdr's log. Is that a hardware specific restriction? Thanks for helping out. -Petri ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.5.0
Petri Helin wrote: > Klaus Schmidinger wrote: >> Petri Helin wrote: >>> Klaus Schmidinger wrote: Petri Helin wrote: > Klaus Schmidinger wrote: >> Looks like the CAM is recognized all right. >> >> Please enable the lines >> >> static bool DumpTPDUDataTransfer = false; >> static bool DebugProtocol = false; >> static bool DumpPolls = false; >> static bool DumpDateTime = false; >> >> in ci.c by changing them to 'true' and compile/run VDR again, >> redirecting >> stderr into a file, as in >> >> ./vdr 2> ci.txt >> >> Then send me the resulting output after trying to switch to an >> encrypted >> channel. >> > Attached. Everything looks fine, the CaPmt is sent to the CAM and the communication with the CAM is stable. It should work. Can you please do the same with VDR 1.4 and send me the result of that, too? >>> ... >>> Here you are. >> >> Ah, now I see the difference: >> >> 3: ==> Ca Pmt >> 4 --> 00 01 A0 2F 01 90 02 00 03 9F 80 32 26 03 01 35 01 00 07 >> 01 09 04 0B 00 E0 68 02 02 06 00 00 04 02 AE 00 00 04 02 AF 00 00 04 >> 02 AC 00 00 04 02 AD 00 00 >> >> Slot 1: ==> Ca Pmt (3) 3 3 >> 1: --> 00 01 A0 10 01 90 02 00 03 9F 80 32 07 03 00 00 01 00 01 03 >> >> For some reason VDR 1.4.4 sends the CA descriptors in the CaPmt, while >> VDR 1.5.0 >> doesn't. >> >> Please post the channels.conf entry for the channel you are trying to >> tune to. >> >> Also, just to make sure: are you using plain vanilla VDR 1.5.0 or are >> there >> any patches involved? >> >> Klaus >> >> ___ >> vdr mailing list >> vdr@linuxtv.org >> http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr >> > > Here are the channels that VDR 1.5.0 cannot tune to: > > > Canal+ > Mix;Telenor:266000:C0M128:C:6900:518:686=nor,687=fin,684=sve,685=dan:581:1:309:0:9:0 > > Canal+ Film > 1;Telenor:266000:C0M128:C:6900:512:650=sve,651=dan,652=nor,653=fin;654=eng:576:1:301:0:9:0 > > Canal+ Film > 2;Telenor:266000:C0M128:C:6900:515:682=nor,683=fin,680=sve,681=dan;679=eng:579:1:308:0:9:0 > > Canal+ Film > 3;Telenor:314000:C0M128:C:6900:518:664=sve,665=dan,666=nor,667=fin;668=eng:577:1:3307:0:19:0 > > Canal+ HD;Telenor:33:C0M256:C:6900:512:640;641=eng:580:1:3306:0:22:0 > Canal+ Sport 1;Telenor:266000:C0M128:C:6900:514:670=fin:577:1:305:0:9:0 > Canal+ Sport > 2;Telenor:314000:C0M128:C:6900:519:672=sve,673=dan,674=nor,675=fin:578:1:3308:0:19:0 Ah, just as I thought. Please set the CA parameter of these channels to 0 (FTA) and tune to them again. VDR should automatically insert the correct CA values then. >From the HISTORY: - Ca values in the range 0...F in channels.conf can still be used to assign a channel to a particular device, but this will no longer work with encrypted channels because without valid CA ids VDR can't decide which CAM slot to use. However, since VDR now automatically determines which CAM can decrypt which channel, setting fixed channel/device relations should no longer be necessary. Klaus ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.5.0
Klaus Schmidinger wrote: Petri Helin wrote: Klaus Schmidinger wrote: Petri Helin wrote: Klaus Schmidinger wrote: Looks like the CAM is recognized all right. Please enable the lines static bool DumpTPDUDataTransfer = false; static bool DebugProtocol = false; static bool DumpPolls = false; static bool DumpDateTime = false; in ci.c by changing them to 'true' and compile/run VDR again, redirecting stderr into a file, as in ./vdr 2> ci.txt Then send me the resulting output after trying to switch to an encrypted channel. Attached. Everything looks fine, the CaPmt is sent to the CAM and the communication with the CAM is stable. It should work. Can you please do the same with VDR 1.4 and send me the result of that, too? ... Here you are. Ah, now I see the difference: 3: ==> Ca Pmt 4 --> 00 01 A0 2F 01 90 02 00 03 9F 80 32 26 03 01 35 01 00 07 01 09 04 0B 00 E0 68 02 02 06 00 00 04 02 AE 00 00 04 02 AF 00 00 04 02 AC 00 00 04 02 AD 00 00 Slot 1: ==> Ca Pmt (3) 3 3 1: --> 00 01 A0 10 01 90 02 00 03 9F 80 32 07 03 00 00 01 00 01 03 For some reason VDR 1.4.4 sends the CA descriptors in the CaPmt, while VDR 1.5.0 doesn't. Please post the channels.conf entry for the channel you are trying to tune to. Also, just to make sure: are you using plain vanilla VDR 1.5.0 or are there any patches involved? Klaus ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr Here are the channels that VDR 1.5.0 cannot tune to: Canal+ Mix;Telenor:266000:C0M128:C:6900:518:686=nor,687=fin,684=sve,685=dan:581:1:309:0:9:0 Canal+ Film 1;Telenor:266000:C0M128:C:6900:512:650=sve,651=dan,652=nor,653=fin;654=eng:576:1:301:0:9:0 Canal+ Film 2;Telenor:266000:C0M128:C:6900:515:682=nor,683=fin,680=sve,681=dan;679=eng:579:1:308:0:9:0 Canal+ Film 3;Telenor:314000:C0M128:C:6900:518:664=sve,665=dan,666=nor,667=fin;668=eng:577:1:3307:0:19:0 Canal+ HD;Telenor:33:C0M256:C:6900:512:640;641=eng:580:1:3306:0:22:0 Canal+ Sport 1;Telenor:266000:C0M128:C:6900:514:670=fin:577:1:305:0:9:0 Canal+ Sport 2;Telenor:314000:C0M128:C:6900:519:672=sve,673=dan,674=nor,675=fin:578:1:3308:0:19:0 My 1.5.0 is unpatched, but 1.4.4 has been patched with liemikuutio-patch and patches needed for ttxtsubs- and subtitles-plugins. -Petri ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.5.0
Petri Helin wrote:
> Klaus Schmidinger wrote:
>> Petri Helin wrote:
>>> ...
>>> BTW: I have been patching the device.c in 1.4.* series so that my other
>>> card, TT budget DVB-C v1.0, is always preferred for FTA channel
>>> recordings. Otherwise the precious CAM could be wasted in an FTA
>>> recording. I understood that you are planning on restructuring the
>>> priority model in 1.5.*. Have you taken in consideration the situation
>>> with budget-only environment with one or more CIs?
>>
>> Please try the attached patch and let me know if it works
>> as expected.
>>
>> Klaus
>>
>
> Unfortunately it didn't work as (at least I) expected. What I am looking
> for is as follows
>
> - card 1 (with CI) is tuned to channel A
Does this mean that there are receivers attached to card 1?
If so, VDR of course starts the new recording on card 1 in
order to keep card 2 available for other recordings.
> - card 2 (without CI) is tuned to channel B
> - channels A and B are on on different transponders
> - a recording is about to start on channel A
> - VDR chooses card 2 and tunes it to channel A in order to actuate the
> recording
>
> Currently I have achieved this with the attached patch.
>
> -Petri
>
>
>
>
> --- vdr-1.4.4/device.c.orig 2006-09-03 13:13:25.0 +0300
> +++ vdr-1.4.4/device.c2006-12-11 20:46:13.0 +0200
> @@ -292,11 +292,11 @@
> // to their individual severity, where the one listed first will
> make the most
> // difference, because it results in the most significant bit of
> the result.
> uint imp = 0;
> + 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]->Receiving() || 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] == cTransferControl::ReceiverDevice();
> // avoid the Transfer Mode receiver device
> 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 would mean that if a recording is currently running on card 1 (with CI),
and another recording on the same transponder shall be started, that new
recording would use card 2, thus blocking the possibility of a third recording
on a different transponder.
Klaus
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.5.0
Petri Helin wrote: > Klaus Schmidinger wrote: >> Petri Helin wrote: >>> Klaus Schmidinger wrote: Looks like the CAM is recognized all right. Please enable the lines static bool DumpTPDUDataTransfer = false; static bool DebugProtocol = false; static bool DumpPolls = false; static bool DumpDateTime = false; in ci.c by changing them to 'true' and compile/run VDR again, redirecting stderr into a file, as in ./vdr 2> ci.txt Then send me the resulting output after trying to switch to an encrypted channel. >>> Attached. >> >> Everything looks fine, the CaPmt is sent to the CAM and the >> communication with the CAM is stable. It should work. >> >> Can you please do the same with VDR 1.4 and send me the result of >> that, too? > ... > Here you are. Ah, now I see the difference: 3: ==> Ca Pmt 4 --> 00 01 A0 2F 01 90 02 00 03 9F 80 32 26 03 01 35 01 00 07 01 09 04 0B 00 E0 68 02 02 06 00 00 04 02 AE 00 00 04 02 AF 00 00 04 02 AC 00 00 04 02 AD 00 00 Slot 1: ==> Ca Pmt (3) 3 3 1: --> 00 01 A0 10 01 90 02 00 03 9F 80 32 07 03 00 00 01 00 01 03 For some reason VDR 1.4.4 sends the CA descriptors in the CaPmt, while VDR 1.5.0 doesn't. Please post the channels.conf entry for the channel you are trying to tune to. Also, just to make sure: are you using plain vanilla VDR 1.5.0 or are there any patches involved? Klaus ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.5.0
Klaus Schmidinger wrote: Petri Helin wrote: Klaus Schmidinger wrote: Looks like the CAM is recognized all right. Please enable the lines static bool DumpTPDUDataTransfer = false; static bool DebugProtocol = false; static bool DumpPolls = false; static bool DumpDateTime = false; in ci.c by changing them to 'true' and compile/run VDR again, redirecting stderr into a file, as in ./vdr 2> ci.txt Then send me the resulting output after trying to switch to an encrypted channel. Attached. Everything looks fine, the CaPmt is sent to the CAM and the communication with the CAM is stable. It should work. Can you please do the same with VDR 1.4 and send me the result of that, too? Klaus ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr Here you are. -Petri ci-1.4.4.txt.gz Description: application/gzip ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.5.0
Klaus Schmidinger wrote:
Petri Helin wrote:
...
BTW: I have been patching the device.c in 1.4.* series so that my other
card, TT budget DVB-C v1.0, is always preferred for FTA channel
recordings. Otherwise the precious CAM could be wasted in an FTA
recording. I understood that you are planning on restructuring the
priority model in 1.5.*. Have you taken in consideration the situation
with budget-only environment with one or more CIs?
Please try the attached patch and let me know if it works
as expected.
Klaus
Unfortunately it didn't work as (at least I) expected. What I am looking
for is as follows
- card 1 (with CI) is tuned to channel A
- card 2 (without CI) is tuned to channel B
- channels A and B are on on different transponders
- a recording is about to start on channel A
- VDR chooses card 2 and tunes it to channel A in order to actuate the
recording
Currently I have achieved this with the attached patch.
-Petri
--- vdr-1.4.4/device.c.orig 2006-09-03 13:13:25.0 +0300
+++ vdr-1.4.4/device.c 2006-12-11 20:46:13.0 +0200
@@ -292,11 +292,11 @@
// to their individual severity, where the one listed first will make the most
// difference, because it results in the most significant bit of the result.
uint imp = 0;
+ 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]->Receiving() || 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] == cTransferControl::ReceiverDevice();// avoid the Transfer Mode receiver device
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) {
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.5.0
Petri Helin wrote: > Klaus Schmidinger wrote: >> >> Looks like the CAM is recognized all right. >> >> Please enable the lines >> >> static bool DumpTPDUDataTransfer = false; >> static bool DebugProtocol = false; >> static bool DumpPolls = false; >> static bool DumpDateTime = false; >> >> in ci.c by changing them to 'true' and compile/run VDR again, redirecting >> stderr into a file, as in >> >> ./vdr 2> ci.txt >> >> Then send me the resulting output after trying to switch to an encrypted >> channel. >> > > Attached. Everything looks fine, the CaPmt is sent to the CAM and the communication with the CAM is stable. It should work. Can you please do the same with VDR 1.4 and send me the result of that, too? Klaus ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.5.0
Klaus Schmidinger wrote: Looks like the CAM is recognized all right. Please enable the lines static bool DumpTPDUDataTransfer = false; static bool DebugProtocol = false; static bool DumpPolls = false; static bool DumpDateTime = false; in ci.c by changing them to 'true' and compile/run VDR again, redirecting stderr into a file, as in ./vdr 2> ci.txt Then send me the resulting output after trying to switch to an encrypted channel. Attached. -Petri ci.txt.gz Description: application/gzip ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.5.0
Petri Helin wrote:
> ...
> BTW: I have been patching the device.c in 1.4.* series so that my other
> card, TT budget DVB-C v1.0, is always preferred for FTA channel
> recordings. Otherwise the precious CAM could be wasted in an FTA
> recording. I understood that you are planning on restructuring the
> priority model in 1.5.*. Have you taken in consideration the situation
> with budget-only environment with one or more CIs?
Please try the attached patch and let me know if it works
as expected.
Klaus
===
RCS file: RCS/device.c
retrieving revision 1.138
diff -u -r1.138 device.c
--- device.c 2007/01/07 13:41:07 1.138
+++ device.c 2007/01/13 12:05:00
@@ -334,6 +334,7 @@
imp <<= 8; imp |= min(max((NumUsableSlots ? SlotPriority[j] : 0) + MAXPRIORITY, 0), 0xFF); // use the CAM slot with the lowest priority (+MAXPRIORITY to assure that values -99..99 can be used)
imp <<= 1; imp |= ndr; // avoid devices if we need to detach existing receivers
imp <<= 1; imp |= device[i]->IsPrimaryDevice(); // avoid the primary device
+ 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
if (imp < Impact) {
@@ -367,6 +368,11 @@
return d;
}
+bool cDevice::HasCi(void)
+{
+ return false;
+}
+
void cDevice::SetCamSlot(cCamSlot *CamSlot)
{
camSlot = CamSlot;
===
RCS file: RCS/device.h
retrieving revision 1.80
diff -u -r1.80 device.h
--- device.h 2007/01/03 14:14:29 1.80
+++ device.h 2007/01/13 11:33:57
@@ -314,6 +314,8 @@
time_t startScrambleDetection;
cCamSlot *camSlot;
public:
+ virtual bool HasCi(void);
+ ///< Returns true if this device has a Common Interface.
void SetCamSlot(cCamSlot *CamSlot);
///< Sets the given CamSlot to be used with this device.
cCamSlot *CamSlot(void) const { return camSlot; }
===
RCS file: RCS/dvbdevice.c
retrieving revision 1.161
diff -u -r1.161 dvbdevice.c
--- dvbdevice.c 2007/01/05 11:09:51 1.161
+++ dvbdevice.c 2007/01/13 11:37:00
@@ -509,6 +509,11 @@
return spuDecoder;
}
+bool cDvbDevice::HasCi(void)
+{
+ return ciAdapter;
+}
+
uchar *cDvbDevice::GrabImage(int &Size, bool Jpeg, int Quality, int SizeX, int SizeY)
{
if (devVideoIndex < 0)
===
RCS file: RCS/dvbdevice.h
retrieving revision 1.42
diff -u -r1.42 dvbdevice.h
--- dvbdevice.h 2007/01/05 10:39:52 1.42
+++ dvbdevice.h 2007/01/13 11:35:07
@@ -84,6 +84,11 @@
protected:
virtual int OpenFilter(u_short Pid, u_char Tid, u_char Mask);
+// Common Interface facilities:
+
+public:
+ virtual bool HasCi(void);
+
// Image Grab facilities
private:
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.5.0
Petri Helin wrote: > Klaus Schmidinger wrote: >> VDR developer version 1.5.0 is now available at >> ... > with a quick test with this new version I was unable to get the > decrypting to work. I have a Technotrend C1500 budget card with budget > CI and a Dual CAM Irdeto + Conax (Conax is used). This combinations > works flawlessly with 1.4.* series. Here are some relevant log entries: > > Jan 8 00:00:14 localhost vdr: [12494] video directory scanner thread > started (pid=12493, tid=12494) > Jan 8 00:00:14 localhost vdr: [12495] video directory scanner thread > started (pid=12493, tid=12495) > Jan 8 00:00:14 localhost vdr: [12493] probing /dev/dvb/adapter0/frontend0 > Jan 8 00:00:14 localhost vdr: [12497] CI adapter on device 0 thread > started (pid=12493, tid=12497) > Jan 8 00:00:14 localhost vdr: [12495] video directory scanner thread > ended (pid=12493, tid=12495) > Jan 8 00:00:14 localhost vdr: [12494] video directory scanner thread > ended (pid=12493, tid=12494) > Jan 8 00:00:14 localhost vdr: [12497] CAM 1: module present > Jan 8 00:00:14 localhost vdr: [12493] probing /dev/dvb/adapter1/frontend0 > Jan 8 00:00:14 localhost vdr: [12498] tuner on device 1 thread started > (pid=12493, tid=12498) > Jan 8 00:00:14 localhost vdr: [12499] section handler thread started > (pid=12493, tid=12499) > Jan 8 00:00:14 localhost vdr: [12493] probing /dev/dvb/adapter2/frontend0 > Jan 8 00:00:14 localhost vdr: [12493] found 2 video devices > ... > Jan 8 00:00:17 localhost vdr: [12497] CAM 1: module ready > Jan 8 00:00:20 localhost vdr: [12497] CAM 1: Conax 4.00e, 01, 0B00, 04B1 > Jan 8 00:00:24 localhost vdr: [12497] CAM 1: doesn't reply to QUERY - > only a single channel can be decrypted > Jan 8 00:00:24 localhost vdr: [12493] switching to channel 11 Looks like the CAM is recognized all right. Please enable the lines static bool DumpTPDUDataTransfer = false; static bool DebugProtocol = false; static bool DumpPolls = false; static bool DumpDateTime = false; in ci.c by changing them to 'true' and compile/run VDR again, redirecting stderr into a file, as in ./vdr 2> ci.txt Then send me the resulting output after trying to switch to an encrypted channel. > BTW: I have been patching the device.c in 1.4.* series so that my other > card, TT budget DVB-C v1.0, is always preferred for FTA channel > recordings. Otherwise the precious CAM could be wasted in an FTA > recording. I understood that you are planning on restructuring the > priority model in 1.5.*. Have you taken in consideration the situation > with budget-only environment with one or more CIs? This would require additional information in cDevice::GetDevice() to see whether the device has CA capabilities. Until now this is implicitly done by avoiding full featured cards, but since budget cards also can have CAMs I'll add an appropriate check for this to the cDevice class. Klaus ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.5.0
Klaus Schmidinger wrote: VDR developer version 1.5.0 is now available at ftp://ftp.cadsoft.de/vdr/Developer/vdr-1.5.0.tar.bz2 A 'diff' against the latest stable version is available at ftp://ftp.cadsoft.de/vdr/Developer/vdr-1.4.5-1.5.0.diff WARNING: This is a *developer* version. Even though *I* use it in my productive environment, I strongly recommend that you only use it under controlled conditions and for testing and debugging. This version focuses mainly on improvements in CAM handling. The highlights are: - Improved CAM menu and reset handling. - Automatic selection of suitable CAM in a system with several CAMs that claim to decrypt a given channel. - Decrypting of several channels on the same transponder (if the CAM is able to do this). The changes since version 1.4.5: - The CAM handling has been refactored. Instead of a cCiHandler per device there is now an abstract cCiAdapter and a cCamSlot. This allows each slot to be accessed individually. - The general 15 seconds workaround time before opening the CAM menu has been removed. If the CAM menu doesn't open within a timeout, the enter menu command is now sent again. - If a CAM is reset or pulled and reinserted, it now automatically starts decrypting the current channel again. - The Setup/CAM menu now dynamically refreshes its items and displays whether a CAM is present or ready. The 'Reset' function no longer leaves the menu. - The CAM menu will now be openend when pressing the Ok key on a slot entry. - The CAM menu now stays within the current menu context and doesn't close and reopen the menu every time an option is selected. - When an encrypted channel is switched to for the first time, VDR now checks explicitly whether a CAM can actually decrypt that channel. If there is more than one CAM in the system that claims to be able to decrypt the channel, they are all tried in turn. To make this possible, an encrypted channel needs to be received in Transfer Mode when it is switched to for the first time, so that VDR can determine whether the TS packets are actually decrypted. Once a channel is known to be decrypted by a particular CAM, the next time it is switched to it will be shown in normal live viewing mode. - A cDevice now automatically detaches all cReceiver objects that receive PIDs that can't be decrypted with the current CAM. A plugin that attaches a cReceiver to a device should therefore watch the receiver's IsAttached() function to see if it is still attached to the device. - The cReceiver constructor no longer takes an 'int Ca' as its first parameter, but rather a 'tChannelID ChannelID'. This is necessary for the device to be able to determine which CAM a particular channel can be decrypted with. If the channel is known to be unencrypted, or a plugin doesn't want to provide the channel id for other reasons, an invalid tChannelID() can be given. - The cThread::Start() function now waits until a previous incarnation of this thread has actually stopped. Before this it could happen that a thread's Cancel(-1) function was called and immediately after that it was started again, but the Start() function still found it to be 'active'. - The parameter NeedsDetachReceivers in cDevice::GetDevice(const cChannel *Channel, ...) has been removed. A call to this function will automatically detach all receivers from the device if it returns a non-NULL pointer. - The cTimeMs class now accepts an initial timeout value in its constructor. - A CAM is now explicitly instructed to stop decrypting when switching away from an encrypted channel. - If the CAM in use can decrypt several channels at the same time, VDR can now make use if this capability. Whether or not a CAM can decrypt more than one channel is determined by sending it an initial empty QUERY command and testing whether it replies to it. - Ca values in the range 0...F in channels.conf can still be used to assign a channel to a particular device, but this will no longer work with encrypted channels because without valid CA ids VDR can't decide which CAM slot to use. However, since VDR now automatically determines which CAM can decrypt which channel, setting fixed channel/device relations should no longer be necessary. KNOWN BUG - PLEASE HELP DEBUGGING: Start VDR with only one FF DVB card and an attached CI with a CAM. Switch to an encrypted channel for the first time, the channel is shown in Transfer Mode. Wait for at least 10 seconds, so that VDR will mark the CAM as "able to decrypt this channel". Now switch to the same channel again (by selecting it from the Channels menu or typing in its number), and the screen goes black. VDR is now receiving the channel in normal live mode (no Transfer Mode). Apparently there is a problem with switching to live mode after using Transfer Mode. The problem goes away if you switch to a channel on a different transponder and then back to the original one.
