Control of TV from a local network

Registered by Jim Hodapp on 2012-05-02

A session to discuss the options surround control of an Ubuntu TV from a local network. Example: a remote control app on another device and an EPG guide on another device.

Blueprint information

Not started
Will Cooke
Jim Hodapp
Needs approval
Series goal:
Milestone target:

Related branches



[saviq] How much can DLNA provide for a public API, then how much must come from another technology?

[phako] Doing this with DLNA would indeed save lots of design and implementation effort and provide some generally desirable functionality, or even DLNA certification, for free.

So let's clarify the terminology. DLNA is a set of tightened rules and more precise media information
on-top of UPnP/AV. The technology we're talking about when saying DLNA is UPnP which in turn
means SOAP, SSDP, HTTP, GENA notification and a set of XML files describing the available
services and methods.

UPnP and DLNA allow custom services and even methods to be added to existing devices or services
as long as the UPnP requirements defined in the Unified Device Architecture
( are met.

As we've shown with Nokia's N9 it is possible to get DLNA certification with a custom service.
On the N9 we have added a custom service that is needed for XBox 360 compatibility.

However, DLNA and UPnP already specify some useful features for Ubuntu-TV's "control" requirements:

1. By implementing a DLNA/UPnP Renderer, you would already be required to support a certain set of services, which could be used by a device (Controller).

- ConnectionManager: List supported media formats and provide connection control for devices
  that support multiple parallel connections (e.g. rendering several media files at the same
  time; rarely implemented). Note that this does NOT include ACL:
- RenderingControl. Control volume, brightness, hue etc.:
- AVTransport: Set Media file, control playback (start/stop/pause/record)

Rygel implements this rendering device out-of-the box with a simple GStreamer back-end.

There are later versions of these UPnP standards available, but the old DLNA 2009 specification requires those UPnP services to be UPnP V1. The DNLA 2011 specification allows UPnP/AV V2, but the current certification test is still based on the DLNA 2009 version.

2. By also implementing a DLNA/UPnP Media Server, you could also provide EPG information to the same device (Controller).

Introduced as an addendum to the 2009 standard, in the latest incarnation of the DLNA standard
(2011) two new device profiles have been introduced: +SR+ (ScheduledRecording) and +EPG+.
"+SR+" means implementation of a service called ScheduledRecording to handle PVR functionality,
which is defined in version 2 of the UPnP/AV standard:

EPG data is represented via special items in an UPnP/DLNA MediaServer. The definition for
the EPG data is in the ContentDirectory standard:, cf.

+SR+ can actually be in a Renderer/Player instead, but it generally makes sense in a Media Server.

Please note that there currently seems to be no way to certify +EPG+ and +SR+ capabilities. The
testing tool (as mentioned before) is based on the 2009 standard and does not include addendum
specifications. This would likely need coordination with the DLNA if certification is a target.

EPG data should be easy to add to Rygel as it's "just" a new class of objects/containers. ScheduledRecording, while being a long-standing todo-item (to be implemented with gnome-dvb-daemon as a back-end), is currently not supported. But as the basic UPnP infrastructure is well-defined and tested, it shouldn't be to much of an issue.

[murrayc] Jens' blog post has a demo that shows a rough example of using a DLNA Controller to control Totem (when Totem is a DLNA Renderer):


Work Items