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
