This is a "plugin" for the Video Disk Recorder (VDR). Written by: Sascha Volkenandt Current maintainer: Frank Schmirler Project's homepage: http://streamdev.vdr-developer.org/ Former project homepage: http://linux.kompiliert.net/ Latest version available at: http://streamdev.vdr-developer.org/ See the file COPYING for license information. Contents: --------- 1. Description 2. Installation 2.1 VDR 1.2.X 2.2 VDR 1.3.X and above 3. Usage 3.1 Usage HTTP server 3.2 Usage VDR-to-VDR server 3.3 Usage VDR-to-VDR client 4. Other useful Plugins 5. Known Problems 1. Description: --------------- This PlugIn is a VDR implementation of the VTP (Video Transfer Protocol) Version 0.0.3 (see file PROTOCOL) and a basic HTTP Streaming Protocol. It consists of a server and a client part, but both parts are compiled together with the PlugIn source, but appear as separate PlugIns to VDR. The client part acts as a full Input Device, so it can be used in conjunction with a DXR3-Card, XINE, SoftDevice or others to act as a working VDR installation without any DVB-Hardware including EPG-Handling. The server part acts as a Receiver-Device and works transparently in the background within your running VDR. It can serve multiple clients and it can distribute multiple input streams (i.e. from multiple DVB-cards) to multiple clients using the native VTP protocol (for VDR-clients), or using the HTTP protocol supporting clients such as XINE, MPlayer and so on. With XMMS or WinAMP, you can also listen to radio channels over a HTTP connection. It is possible to attach as many clients as the bus and network can handle, as long as there is a device which can receive a specific channel. Multiple channels homed on the same transponder (which is determined by it's frequency) can be broadcasted with a single device. Additional clients can be programmed using the Protocol Instructions inside the PROTOCOL file. 2. Installation: ---------------- Let's say streamdev's version is 0.3.1 and vdr's version is 1.X.X. If you use anything else please exchange the version numbers appropriately (this way I don't have to update this section all the times;) ). After compiling the PlugIn as stated below, start either (or both) parts of it by specifying "-P streamdev-client" and/or "-P streamdev-server" on the VDR command line. What's important is that the client requests a channel using its Unique Channel ID. So, in order to find the channel at the server, it must have the same ID that is used on the client. You can achieve this by putting the server's channels.conf on the client, preferably after scanning (in case you use 1.2.X with AutoPID or 1.3.X). If you want to drive additional Input-Devices (with different sources) on the client, you can merge the channels.conf files. VDR will detect if the local device or the network device can receive the channels. Last, but not least you have to put the provided streamdevhosts.conf.example into the "plugins" subfolder of your config-directory (which is equal to your video-directory if not specified otherwise), rename it to streamdevhosts.conf and adjust it to your needs. The syntax is the same as for svdrphosts.conf, so please consult VDR's documentation on how to fill that file, if you can't do it on-the-fly. For example, if you didn't specify a separate config-directory, and specified your video directory as "/video0", the file has to be put to /video0/plugins/streamdevhosts.conf. 2.1 VDR 1.2.X: -------------- It is recommended that you apply a patch to VDR that improves thread cancellation. You can work without it, but you _might_ have delays in switching (especially when using VDR-to-VDR streaming) that are around three seconds. cd vdr-1.X.X/PLUGINS/src tar xvfz vdr-streamdev-0.3.1.tgz ln -s streamdev-0.3.1 streamdev cd ../.. patch -p1 " on your remote. If you want to enter "192.168.1.12", type "192168112". The parameters "Remote IP" and "Remote Port" in the client's setup specify the address of the remote VDR-to-VDR server to connect to. Activate the client by setting "Start Client" to yes. It is disabled by default, because it wouldn't make much sense to start the client without specifying a server anyway. The client is activated after you push the OK button, so there's no need to restart VDR. Deactivation on-the-fly is not possible, so in order to deactivate the client, you will have to restart VDR. All other settings can be changed without restarting VDR. The client will try to connect to the server (in case it isn't yet) whenever a remote channel is requested. Just activate the client and switch to a channel that's not available by local devices. If anything goes wrong with the connection between the two, you will see it in the logfile instantly. If you now switch the client to a channel which isn't covered by it's own local devices, it will ask the server for it. If the server can (currently) receive that channel, the client will show it until you switch again, or until the server needs that card (if no other is free) for a recording on a different transponder. Only the needed PIDs are transferred, and additional PIDs can be turned on during an active transfer. This makes it possible to switch languages, receive additional channels (for recording on the client) and use plugins that use receivers themselves (like osdteletext). With "Filter Streaming" enabled, the client will receive meta information like EPG data and service information, just as if the client had its own DVB card. Link channels and even a client-side EPG scan have been reported to work. The last parameter, "Synchronize EPG", will have the client synchronize it's program table with the server every now and then, but not regularly. This happens when starting the client, and everytime VDR does its housekeeping tasks. The only thing that's guaranteed is, that there will be a minimum interval of ten seconds between each EPG synchronization. With "Filter Streaming" this option has been obsoleted. If you still need to synchronize EPG as additional information is available from the server, you should use the epgsync-plugin instead (http://vdr.schmirler.de). 4. Other useful Plugins: ------------------------ 4.1 Plugins for VDR-to-VDR clients: ----------------------------------- The following plugins are useful for VDR-to-VDR clients (i.e. VDRs running the streamdev-client): * remotetimers (http://vdr.schmirler.de/) Add, edit, delete timers on client and server * timersync (http://phivdr.dyndns.org/vdr/vdr-timersync/) Automatically syncronizes timer lists of client and server. All recordings will be made on the server * remoteosd (http://vdr.schmirler.de/) Provides access to the server's OSD menu * epgsync (http://vdr.schmirler.de/) Import EPG from server VDR * femon (http://www.saunalahti.fi/~rahrenbe/vdr/femon/) Display signal information from server's DVB card. SVDRP support must be enabled in femon's setup 4.2 Plugins for Server: ----------------------- * dummydevice (http://phivdr.dyndns.org/vdr/vdr-dummydevice/) Recommended on a headless server (i.e. a server with no real output device). Without this plugin, a budget DVB card could become VDR's primary device. This causes unwanted sideeffects in certain situations. 4.3 Alternatives: ----------------- * xineliboutput (http://phivdr.dyndns.org/vdr/vdr-xineliboutput/) With its networking option, xineliboutput provides an alternative to streamdev. You will get the picture of the server VDR, including its OSD. However you won't get independent clients, as they all share the same output. 5. Known Problems: ------------------ * In VDR-to-VDR setup, the availability of a channel is checked with a different priority than the actual channel switch. The later always uses priority 0. Usually a channel switch for live TV has priority 0 anyway, so it is not a problem here. However timers usually have a higher priority. Either avoid client side recordings or set the priority of client side timers to 0.