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. Now it is shown even in normal live mode.
I did a lot of debugging to find out why this goes wrong, but was unable to fix it. Maybe somebody out there can find out why this doesn't work.
Have fun!
Klaus
Klaus Schmidinger wrote:
VDR developer version 1.5.0 is now available at
ftp://ftp.cadsoft.de/vdr/Developer/vdr-1.5.0.tar.bz2A 'diff' against the latest stable version is available at
ftp://ftp.cadsoft.de/vdr/Developer/vdr-1.4.5-1.5.0.diffWARNING:
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. Now it is shown even in normal live mode.
I did a lot of debugging to find out why this goes wrong, but was unable to fix it. Maybe somebody out there can find out why this doesn't work.
Have fun!
Klaus
vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Hi,
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
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?
-Petri
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
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
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
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
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
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:330000: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
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:330000: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
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:330000: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
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
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
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
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 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
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
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 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
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
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
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.000000000 +0300 +++ vdr-1.4.4/device.c 2006-12-11 20:46:13.000000000 +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
-
Heikki Manninen -
Klaus Schmidinger -
Matthias Schniedermeyer -
Petri Helin