Updated README, dropped obsolete patches.

This commit is contained in:
Frank Schmirler 2012-05-12 13:41:45 +02:00
parent 00b7318a7b
commit ab26b4770a
3 changed files with 38 additions and 72 deletions

88
README
View File

@ -101,9 +101,8 @@ as otherwise -r will be passed to VDR and not to streamdev.
2.1 Compatibility: 2.1 Compatibility:
------------------ ------------------
This version is not compatible to VDR releases older than 1.5.9. Take one of This version is not compatible to VDR releases older than 1.7.25. Use one of
the streamdev-0.4.x releases if you are running at least VDR 1.4.x. For older the streamdev-0.5.x releases for older versions.
VDRs you will probably need one of the streamdev-0.3.x releases.
2.2 Compiling: 2.2 Compiling:
-------------- --------------
@ -175,31 +174,32 @@ Start the server core itself by specifying -Pstreamdev-server on your VDR
commandline. To use the client core, specify -Pstreamdev-client. Both parts commandline. To use the client core, specify -Pstreamdev-client. Both parts
can run in one VDR instance, if necessary. can run in one VDR instance, if necessary.
Precedence between multiple clients and between client and server is controlled
with priorities. For HTTP and IGMP Multicast, the priority is configured in
streamdev-server's setup menu. A negative priority gives precedence to local
live TV on the server. Zero and positive values give precedence to the client.
The priority for VDR clients watching live TV is configured in the plugin setup
of streamdev-client. For other client tasks (e.g. recording a client side timer)the same priority as on the client is used. With the parameter "Legacy client
Priority" in streamdev-server's setup menu you can configure the priority for
clients which cannot be configured to use negative priorities. It is used
when an old client is detected an it requests priority "0".
On the server, the main menu entry "Streamdev Connections" gives you a list On the server, the main menu entry "Streamdev Connections" gives you a list
of currently connected clients. Use the "red" key to terminate a connection. of currently connected clients. Use the "red" key to terminate a connection.
Note that depending on connection type and client, the client might re-connect Note that depending on connection type and client, the client might re-connect
sooner or later. Depending on the server setup, the "blue" key might be enabled sooner or later.
as well. Please read below.
The parameter "Suspend behaviour" allows you to specify how the server should The "blue" key in the server's main menu will suspend live TV on server. An
react in case the client requests a channel that would require switching the image is displayed instead. This would allow a low priority client to switch
primary device (i.e. disrupt live-tv). If set to "Offer suspend mode", you to a different transponder. Enable "Client may suspend" in the server setup
enable the "blue" key in the server's main menu. It will put the server into to allow VDR clients to suspend live TV remotely.
"Suspend Mode" (a picture is displayed on TV). Then, a client may switch the
primary card to wherever it likes to. While watching TV (Suspend deactivated),
the client may not switch the transponder on the primary device. If you set
the behaviour to "Always suspended" (the default), there will be normal live-tv
on the server, but whenever a client decides to switch the transponder, the
server will lose it's live-tv. Set to "Never suspended", the server always
prevents the client from switching transponders. If you set "Client may
suspend" to yes, the client can suspend the server remotely (this only applies
if "Offer suspend mode" is selected).
NOTE: This mainly applies to One-Card-Systems, since with multiple cards there NOTE: Precedence is mainly an issue on One-Card-Systems, since with multiple
is no need to switch transponders on the primary interface, if on of the other cards there is no need to switch transponders on the primary interface, if on
cards is idle (i.e. if it is not blocked by a recording). If all cards are in of the other cards is idle (i.e. if it is not blocked by a recording). If all
use (i.e. when something is recorded, or by multiple clients), this applies to cards are in use (i.e. when something is recorded, or by multiple clients), this
Multiple-Card-Systems as well. applies to Multiple-Card-Systems as well.
3.1 Usage HTTP server: 3.1 Usage HTTP server:
---------------------- ----------------------
@ -288,13 +288,6 @@ reserved according to RFC-2365).
Before you can use streamdev's multicast server, you might need to patch VDR. Before you can use streamdev's multicast server, you might need to patch VDR.
Binding an IGMP socket is a privileged operation, so you must start VDR as root. Binding an IGMP socket is a privileged operation, so you must start VDR as root.
If you pass the -u option to VDR, it will drop almost all priviledges before
streamdev is even loaded. In VDR < 1.7.22 this prevented streamdev from binding
the socket. Apply either patch vdr-1.6.0-cap_net_raw.diff (VDR < 1.7.5) or
vdr-1.7.21-cap_net_raw.diff (VDR < 1.7.22) to keep VDR from dropping capability
CAP_NET_RAW. The patch is part of streamdev's source distribution. Check the
patches subdirectory. There's no need to patchif you are running VDR >= 1.7.22
or if VDR is kept running as root (not recommended).
The multicast server is disabled by default. Enter the streamdev-server setup The multicast server is disabled by default. Enter the streamdev-server setup
menu to enable it and - IMPORTANT - bind the multicast server to the IP of your menu to enable it and - IMPORTANT - bind the multicast server to the IP of your
@ -408,22 +401,21 @@ The two parameters define the inclusive range of priorities for which streamdev
will accept to tune. Setting the minimum priority to a higher value than the will accept to tune. Setting the minimum priority to a higher value than the
maximum, you will get two ranges: "up to maximum" and "minimum and above". maximum, you will get two ranges: "up to maximum" and "minimum and above".
If you are running at least VDR 1.7.0, you can also configure the "Broadcast You can also configure the "Broadcast Systems / Cost" of the streamdev-client
Systems / Cost" of the streamdev-client device. On a pure streamdev-client only device. On a pure streamdev-client only system it doesn't matter what you
system it doesn't matter what you configure here. But if your client is equipped configure here. But if your client is equipped with a DVB card, you should read
with a DVB card, you should read on. VDR always prefers the cheapest device on. VDR always prefers the cheapest device in terms of supported broadcast
in terms of supported broadcast systems and modulations. A DVB-S2 card supports systems and modulations. A DVB-S2 card supports two broadcast systems (DVB-S and
two broadcast systems (DVB-S and DVB-S2). From VDR 1.7.15 on, the supported DVB-S2). The supported modulations are counted as well (QPSK, QAM32/64/128/256,
modulations are counted as well (QPSK, QAM32/64/128/256, VSB8/16, TURBO_FEC). VSB8/16, TURBO_FEC). So for a DVB-S2 card which does QPSK you'll get a total
So for a DVB-S2 card which does QPSK you'll get a total cost of three. A DVB-C cost of three. A DVB-C card (one broadcast system) which can do QAM32, QAM64,
card (one broadcast system) which can do QAM32,QAM64,QAM128,QAM256 would give QAM128, QAM256 would give you a total of five. Check your log for "frontend ...
you a total of five. Check your log for "frontend ... provides ... with ..." provides ... with ..." messages to find out the cost of your DVB cards. Then
messages to find out the cost of your DVB cards. Then pick a suitable value for pick a suitable value for streamdev-client. With equal costs, VDR will usually
streamdev-client. With equal costs, VDR will usually prefer the DVB card and prefer the DVB card and take streamdev for recordings. If streamdev's costs are
take streamdev for recordings. If streamdev's costs are higher, live TV will higher, live TV will use your DVB card until a recordings kicks in. Then the
use your DVB card until a recordings kicks in. Then the recording will take the recording will take the DVB card and live TV will be shifted to streamdev
DVB card and live TV will be shifted to streamdev (you'll notice a short (you'll notice a short interruption of live TV).
interruption of live TV).
Note that streamdev-client acts similar to a DVB card. It is possible to receive Note that streamdev-client acts similar to a DVB card. It is possible to receive
multiple channels simultaneously, but only from the same transponder. Just add multiple channels simultaneously, but only from the same transponder. Just add
@ -536,10 +528,6 @@ The script should perform the following steps (pseudocode):
6. Known Problems: 6. Known Problems:
------------------ ------------------
* There have been reports that channel switching with VDR 1.5.x/1.6.x clients
sometimes fails. Current version includes a workaround which seems to work, but
YMMV ;)
* Viewing encrypted channels became an issue with VDR's new CAM handling code. * Viewing encrypted channels became an issue with VDR's new CAM handling code.
Streamdev doesn't provide a (dummy) CAM, so out of the box, VDR won't ever try Streamdev doesn't provide a (dummy) CAM, so out of the box, VDR won't ever try
to receive encrypted channels from streamdev. Pick one of the following to receive encrypted channels from streamdev. Pick one of the following

View File

@ -1,11 +0,0 @@
--- vdr.c.orig 2009-02-13 09:45:55.000000000 +0100
+++ vdr.c 2009-02-13 09:46:24.000000000 +0100
@@ -115,7 +115,7 @@
static bool SetCapSysTime(void)
{
// drop all capabilities except cap_sys_time
- cap_t caps = cap_from_text("= cap_sys_time=ep");
+ cap_t caps = cap_from_text("= cap_sys_time,cap_net_raw=ep");
if (!caps) {
fprintf(stderr, "vdr: cap_from_text failed: %s\n", strerror(errno));
return false;

View File

@ -1,11 +0,0 @@
--- vdr.c.orig 2011-12-09 08:47:52.000000000 +0100
+++ vdr.c 2011-12-09 08:48:14.000000000 +0100
@@ -116,7 +116,7 @@
static bool DropCaps(void)
{
// drop all capabilities except selected ones
- cap_t caps = cap_from_text("= cap_sys_nice,cap_sys_time=ep");
+ cap_t caps = cap_from_text("= cap_sys_nice,cap_sys_time,cap_net_raw=ep");
if (!caps) {
fprintf(stderr, "vdr: cap_from_text failed: %s\n", strerror(errno));
return false;