 |  |
| | |
The VDR itself focuses on the core functions such as DVB reception, recordings an a simple EPG administration. Any additional functionality is provided by plugins. The page Plugins in the VDR Wiki provides a good overview about all plugins and their compatibility with the VDR that is used in yaVDR. Most of the compatible plugins are available in the yaVDR package sources and can be conveniently added to your system via the Web frontend or the Shell.
The Streamdev Plugin enables VDR to stream Live-TV to other VDRs (also equipped with the Streamdev Plugin) or other clients via HTTP. It has two functionalities to act as a Streamdev server or a Streamdev client.
The Streamdev server plugin (package vdr-plugin-streamdev-server) is already pre-installed in yaVDR 0.5. It extends the VDR with the capbility to stream Live-TV into the network.
![[Note]](images/icons/note.png){kind=icon} | Remote Access |
|---|---|
Directy after installation, the plugins limits access to local clients only. To grant access (and control of important functions via SVDRP) to other clients, two configuration files need to customized as described below: |
Access via SVDRP (e.g. when another VDR shall have access via the Streamdev client plugin) requires to customize the file /etc/vdr/svdrphosts.conf as described in the SVDRP section.
Furthermore, access to the transport streams provided by the Streamdev server require changes of the /etv/vdr/plugins/streamdevhosts.conf configuration file. In yaVDR 0.5 this file is templated.
Example entries in /etc/vdr/plugins/streamdevhosts.conf (or the target of the symbolic link /var/lib/vdr/plugins/streamdev-server/streamdevhosts.conf).
127.0.0.1192.168.1.115
192.168.1.0/24
192.168.1.0/16
0.0.0.0/0
| Do not remove this entry! Otherwise, VDR cannot communicate properly with certain plugins! |
| Grants access for the computer with the IP address 192.168.1.115 |
| Grants access for all computers that have an IP address which starts with 192.168.1.xxx |
| Grants access for all computers that have an IP address which starts with 192.168.xxx.yyy (this is a class C network). This is the default access to the Streamdev server. |
| Regardless of the IP address, all computers have access (Caution: this enables unprotected access to the VDR from outside, unless your network is protected by a router with NAT [34] or a firewall!) |
The Streamdev server provides a web interface on port 3000. It offers links to all streams. At http://<IP_of_your_VDR>:3000/channels.m3u, you can download a playlist with all stations. A suitable Streamdev client is e.g. the VLC Media Player.
![[Tip]](images/icons/tip.png){kind=icon} | Streaming of Radio Stations |
|---|---|
If you plan to stream radio stations, please select "ES" [35] for the transmission protocol. This changes the link to the stream to e.g.: http://<IP_of_your_VDR>:3000/ES/C-1-1093-28457 |
| extremux.sh |
|---|---|
The package mencoder needs to be installed to be able to use externremux.sh. An example is available in /var/lib/vdr/plugins/streamdev-server/externremux.sh. |
The Streamdev client plugin (package: vdr-plugin-streamdev-client) enables VDR to access a Streamdev server plugin of another VDR. Thus, it can use the DVB adapters of this VDR. This requires to copy the desired channels in the channels.conf file on the server into the channels.conf file on the client. Also, the connection settings on server and client need to be set up. One instance of a Streamdev client cannot receive more that one transponder at a time.
By default, all clients in a Class C network (IP range 192.168.xxx.yyy) can access the Streamdev server. If you like to have a more fine-grained acess control or like to extend the access to other IP addresses/ranges, please set up /etc/vdr/plugins/streamdev-server/streamdevhosts.conf as described above.
The xvdr plugin enables experimental version of XBMC with PVR support to facilitate VDR as a PVR backend. At the moment, the functions span Live TV, EPG, administration of timers as well as access to VDR recordings. Further functions, e.g. using cut marks, the cutting of recordings or the change of VDR settings from within XBMC is not supported yet. The xvdr plugin supports multiple users. Thus, several XBMC clients can access and VDR at the same time.
The access from remote clients needs to be specified in the file /var/lib/vdr/plugins/xvdr/allowed_hosts.conf. The syntax of this file is identical to the svdrphosts.conf file:
| Remote Access |
|---|---|
Remote access requires the customization of the /var/lib/vdr/plugins/xvdr/allowed_hosts.conf file. Some examples are given below: |
Example entries in /var/lib/vdr/plugins/xvdr/allowed_hosts.conf.
127.0.0.1
| Do not remove this entry! Otherwise, the local access from XBMC to VDR will not work anymore! |
| Grants access for the computer with the IP address 192.168.1.115 |
| Grants access for all computers that have an IP address which starts with 192.168.1.xxx |
| Grants access for all computers that have an IP address which starts with 192.168.xxx.yyy (this is a class C network) |
| Regardless of the IP address, all computers have access (Caution: this enables unprotected access to the VDR from outside, unless your network is protected by a router with NAT [36] or a firewall!) |
The program dfatmo as well the corresponing VDR plugin can be installed by the packages dfatmo and libxine-dfatmo-plugin.[37]
The start arguments for xine resp. vdr-sxfe have to be adjusted in the configuration file /etc/init/vdr-frontend.conf to set up dfatmo. This file is templated. Thus, you should not edit it directly. Instead, copy the particular template section (20_xineliboutput for vdr-sxfe and 25_xine for xine) from /usr/share/yavdr/templates/etc/init/vdr-frontend.conf/ to /etc/yavdr/templates_custom/etc/init/vdr-frontend.conf/ and define the variable XINELIBOUTPUTOPTS resp. XINEOPTS. Finally, compile the new configuration file from the template.
The following instruction provides a step by step guideline:
sudo mkdir -p /etc/yavdr/templates_custom/etc/init/vdr-frontend.conf/
| Creates the directory for the customized template section |
| Copies the requried template files |
Ammend the variables XINE(LIBOUTPUT)OPTS in these files:
XINELIBOUTPUTOPTS="--post tvtime:method=use_vo_driver --reconnect --audio=alsa --syslog --silent --tcp" XINELIBOUTPUTOPTS="$XINELIBOUTPUTOPTS --post=dfatmo:driver=serial,driver_param=/dev/ttyUSB0,top=1,bottom=1,left=1,right=1,brightness=150,analyze_size=0,overscan=0,enabled=1"
resp.
XINEOPTS="-G $GEOMETRY -A alsa --config /etc/xine/config --keymap=file:/etc/xine/keymap --post vdr --post vdr_video --post vdr_audio --verbose=2 --no-gui --no-logo --no-splash --deinterlace -pq" XINEOPTS="$XINEOPTS --post=dfatmo:driver=serial,driver_param=/dev/ttyUSB0,top=1,bottom=1,left=1,right=1,brightness=150,analyze_size=0,overscan=0,enabled=1"
Compile the new configuration file from the template:
process-template /etc/init/vdr-frontend.conf
Finally, restart Openbox:
sudo stop openbox sudo start openbox
The KEY_BRIGHTNESS_CYCLE key has been reserved to toggle Atmolight on/off via the remote control. Vdr-sxfe needs to listen on keypresses between eventlircd and VDR in order to react on this key. The variable XINELIBOUTPUTOPTS has to be ammended with hotkey support and the eventlircd socket:
--hotkeys --lirc=/var/run/lirc/lircd
In /etc/init/vdr.conf, the start argument --lircd=$LIRC has to be removed.
yaVDR 0.5 introduces the newly developed RestfulAPI plugin, which was designed as an alternative to (or also extension of) SVDRP. Instead of direct TCP communication, it supports interacting with the VDR by HTTP requests. The supported formats for VDR responses are HTML, XML and JSON.
Advantages:
Disadvantages:
The API of the plugin can be displayed via this web address: http://<IP of your yaVDR>:8002/info.html
This plugin supports to attach or dettach DVB adapters dynamically in VDR without the neccessity to restart VDR. This may speed up the start of VDR significantly, because e.g. there’s no need anymore to wait for "slow" USB DVB adapters. As soon as these devices are initialized, they will be attached to the VDR with the help of some udev rules. Once this is done, they are ready to be used. A future version of the plugin may introduce an optional, automated shutdown of these adapters. This may save power, and the adapters are supposed to have longer life as well.
| |  | |
 |
