summaryrefslogtreecommitdiff
path: root/PLUGINS.html
diff options
context:
space:
mode:
authorKlaus Schmidinger <kls (at) cadsoft (dot) de>2007-01-07 18:00:00 +0100
committerKlaus Schmidinger <kls (at) cadsoft (dot) de>2007-01-07 18:00:00 +0100
commit66ab78a40f5b57e20142a33484e32c785a0c4017 (patch)
tree2e351bb9df6cc1325d439729646f83b35e2c346d /PLUGINS.html
parenta2096f3beb9f7bf3ba600cf66555628fc899720e (diff)
downloadvdr-patch-lnbsharing-66ab78a40f5b57e20142a33484e32c785a0c4017.tar.gz
vdr-patch-lnbsharing-66ab78a40f5b57e20142a33484e32c785a0c4017.tar.bz2
Version 1.5.0vdr-1.5.0
- 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. IF AN ENCRYPTED CHANNEL CAN'T BE DECRYPTED AND YOU HAVE A CA VALUE IN THE RANGE 0...F FOR THAT CHANNEL, SET IT TO 0 (FTA) AND TUNE TO THE CHANNEL AGAIN.
Diffstat (limited to 'PLUGINS.html')
-rw-r--r--PLUGINS.html47
1 files changed, 46 insertions, 1 deletions
diff --git a/PLUGINS.html b/PLUGINS.html
index 51424ce..71c1b77 100644
--- a/PLUGINS.html
+++ b/PLUGINS.html
@@ -6,7 +6,7 @@
<center><h1>The VDR Plugin System</h1></center>
-<center><b>Version 1.4.1</b></center>
+<center><b>Version 1.5.0</b></center>
<p>
<center>
Copyright &copy; 2006 Klaus Schmidinger<br>
@@ -14,6 +14,10 @@ Copyright &copy; 2006 Klaus Schmidinger<br>
<a href="http://www.cadsoft.de/vdr">www.cadsoft.de/vdr</a>
</center>
<p>
+<!--X1.5.0--><table width=100%><tr><td bgcolor=#FF0000>&nbsp;</td><td width=100%>
+Important modifications introduced in version 1.5.0 are marked like this.
+<!--X1.5.0--></td></tr></table>
+<p>
VDR provides an easy to use plugin interface that allows additional functionality
to be added to the program by implementing a dynamically loadable library file.
This interface allows programmers to develop additional functionality for VDR completely
@@ -72,6 +76,9 @@ structures and allows it to hook itself into specific areas to perform special a
<li><a href="#Devices">Devices</a>
<li><a href="#Audio">Audio</a>
<li><a href="#Remote Control">Remote Control</a>
+<!--X1.5.0--><table width=100%><tr><td bgcolor=#FF0000>&nbsp;</td><td width=100%>
+<li><a href="#Conditional Access">Conditional Access</a>
+<!--X1.5.0--></td></tr></table>
</ul>
</ul>
@@ -1727,6 +1734,7 @@ selecting which channel it shall tune to:
<p><table><tr><td bgcolor=#F0F0F0><pre>
virtual bool ProvidesSource(int Source) const;
+virtual bool ProvidesTransponder(const cChannel *Channel) const;
virtual bool ProvidesChannel(const cChannel *Channel, int Priority = -1, bool *NeedsDetachReceivers = NULL);
virtual bool SetChannelDevice(const cChannel *Channel, bool LiveView);
</pre></td></tr></table><p>
@@ -2038,5 +2046,42 @@ Put(uint64 Code, bool Repeat = false, bool Release = false);
The other parameters have the same meaning as in the first version of this function.
+<!--X1.5.0--><table width=100%><tr><td bgcolor=#FF0000>&nbsp;</td><td width=100%>
+<a name="Conditional Access"><hr><h2>Conditional Access</h2>
+
+<center><i><b>Members only!</b></i></center><p>
+
+Pay TV providers usually encrypt their broadcasts, so that only viewers who
+have the proper smart card can watch them. Such a smart card needs to be inserted
+into a CAM (Conditional Access Module), which in turn goes into a CI (Common
+Interface) slot.
+<p>
+VDR's mechanisms for supporting Conditional Access are mainly the two classes
+<tt>cCiAdapter</tt> and <tt>cCamSlot</tt>. A <tt>cCiAdapter</tt> handles exactly
+one CI, and can provide several CAM slots, represented by the appropriate
+number of <tt>cCamSlot</tt> objects.
+<p>
+In order to decrypt a particular channel, a <tt>cCiAdapter</tt> with a <tt>cCamSlot</tt>
+that contains the necessary CAM will be assigned to a <tt>cDevice</tt>, and exactly
+one of its CAM slots will be activated. Whether or not a <tt>cCiAdapter</tt> can
+be assigned to a particular device depends on the hardware implementation.
+Some devices (like the Siemens/Technotrend DVB cards) are hardwired with their
+CI adapters, so the <tt>cCiAdapter</tt> for these can only be used with one device.
+Other hardware implementations may allow CI adapters and devices to be connected
+through some sort of matrix switch. When trying to decrypt an encrypted channel,
+VDR will automatically select a useful combination of device and CAM slot.
+<p>
+If a plugin implements a derived <tt>cCiAdapter</tt>, it has to implement
+several low level functions that handle the actual data transfer (see <tt>dvbci.c</tt>
+for example). The decision whether the adapter can actually be assigned to different
+devices is made in the function
+
+<p><table><tr><td bgcolor=#F0F0F0><pre>
+virtual bool Assign(cDevice *Device, bool Query = false);
+</pre></td></tr></table><p>
+
+See the description of this function in <tt>ci.h</tt> for details.
+<!--X1.5.0--></td></tr></table>
+
</body>
</html>