VDR Integration

From LinuxMCE
Revision as of 03:47, 25 August 2009 by Ray N (Talk | contribs)

(diff) ←Older revision | view current revision (diff) | Newer revision→ (diff)
Jump to: navigation, search

State Of The Integration

Currently, interaction between LinuxMCE and VDR is mainly done via the SVDR protocol. Remote control is designed to be done with IR remote controls. Scheduling and EPG is done using the VDR OSD. Recordings can be watch either thru the Videos screen, or thru the VDR OSD.

What needs to be done

To have full control over VDR, and to always know, what state VDR is in at any given time, we need to have vdr-plugin. A vdr-plugin has direct access to events happening within VDR, and can export these events to a LinuxMCE VDRPlugin.


A general way of how to control TV apps like VDR or MythTV. I propose that we create a general TVAppPlugin that have all things that we make available in our UI. No matter if it is on-screen or off-screen UIs.

As a second level there is a interface that do VDR or MythTV specifics.

OSD or not OSD

The VDR OSD looks and acts different than the LinuxMCE OSD. Question is, are we going to be able to re-create all the needed pages from the VDR OSD in LinuxMCE screens, and do we want to?


The recordings are currently shown with their filenames vdr.001 to vdr.255 and with a title entry. This does not look nice, and is irritating. The xxx.vdr files should be excluded from the file listing, and the title entry be the only thing visible.

Remote Control

The current VDRPlugin is designed to work with the on-screen orbiter and a regular IR remote control.

Proposed: All Remotes should be handled by lmce. This way we dont need to do any special coding to interface a new remote against vdr everytime someone want to use a remote we dont know about.

We need to create/define what is needed to interface against vdr: Change channel. Pause, Record etc. Play recording. With xine or with vdr?

Offscreen Orbiter

Off-screen orbiters use UI1. The current UI1 remote control for VDR lacks a couple of standard features

  1. No lighting control
  2. No off-screen channel list
  3. No off-screen EPG listing
  4. No off-screen timer settings

The lighting control and channel list can easily be implemented with a new screen. The EPG listing is a different beast, as not all information seems to be provided by the plugin. And there is currently no provisioning for displaying and controlling timer.


Be able to do everything that onscreen orbiter can do.

Different Approach 1

Variant #1

Instead of setting up a VDR system on each MD, only have a single instance on the core. Use the http streaming of the vdr-plugin-streamdev-server to provide live streams to xine.

  1. Add a file entry containing a URL to each channel
  2. Create Playlists containing all channels
  3. Use xine to play the playlists
  4. Have a cron job fill the attributes for the file pointing to the channels
  5. Add a record button to the media remote

Variant #2

this variant need some development. Can potentially replace the way VDR is working now.


  1. Working VDR install on your core.
  2. No vdr on MD.

Create a new TV button that map to a new TV control mechanism/screen. When user want to watch a TV channel Xine is started and fetch the chosen channel/stream from streamdev-server. EPG functionality can be implemented by querying vdr control-plugin and populate an EPG datagrid. We need functionality to map the streams provided by streamdev-server to appropriate channel we get from control-plugin.

Changing channel is just a matter of changing which stream to display. We probably get "follow me" functionality too.

How to handle recording of a channel:

Since we have a working vdr install in our core we can use that instance to schedule recordings.

New functionality need to be added into UpdateMedia (or appropriate place) to handle added recordings. Maybe we can create have a method in the vdr integration that create an ID3 file for the recording with information fetched from epg.