[vdr] [ANNOUNCE] VDR developer version 1.5.0

[Petri Helin]

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