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