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@xxxxxxxxxxx > 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
