mirror of
https://projects.vdr-developer.org/git/vdr-plugin-streamdev.git
synced 2023-10-10 19:16:51 +02:00
Updated README, dropped obsolete patches.
This commit is contained in:
parent
00b7318a7b
commit
ab26b4770a
88
README
88
README
@ -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
|
||||||
|
@ -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;
|
|
@ -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;
|
|
Loading…
Reference in New Issue
Block a user