Chef de Cambuse, cruising and wine

media collection playing - the DLNA way

written by Frank, on Apr 23, 2009 3:00:00 PM.

Media collections - being it all songs from one album, a list of favorites, or an image slideshow - have not attracted much attention in the world of UPnP A/V.

Of course there are the ContentDirectory objects playlistContainer and playlistItem, but these - if at all - are mostly used to point to some M3U file. And in addition, the client has to support that format. Another drawback is that M3U files don’t fit very well into the UPnP A/V philosophy. A ControlPoint will only know about the M3U file, but not which item of it is played at the moment. Or what metadata is associated with that item. Neither are next and previous operations implementable.

So the task of handling the collection was handed off to the ControlPoint. It was responsible now for holding a list of items to play and to instruct the MediaRenderer to load and play the next item in the list the moment the previous was finished. With the drawback that this list has to be created somehow first.

Same for the autonomous MediaClient, like the Playstation 3 or the XBox 360, their internal part of a ControlPoint usually just continues with the next item in the container.

Now that wasn’t a big issue in the days when we had only autistic autonomous MediaClients, but now more and more real MediaRenderers - meaning alongside to their internal client UI they are (remote) controllable by a ControlPoint - are available. The new Sony Bravia TV 4500 or 5500 series are maybe the most prominent example.

But the DLNA specification offers an interesting approach - they created the dlna-playcontainer URI.

That’s the uri for an additional res element a MediaServer can add automatically to an existent container.
Encoded in the uri is

  • the UDN of the device, the MediaServer
  • the service type, usually a ContentDirectory
  • the container id
  • the id of the first item
  • the index of the first item
  • the optional sort-criteria
  • the max-depth information - aka the level of subcontainers, optional too
It looks a bit like this:


With that information a MediaRenderer is now able to call a Browse action on the ContentDirectory service of that device and retrieve all the items of that container. And propagate with AVTransportURI/AVTransportURIMetaData the “dlna-playcontainer” uri and with CurrentTrackURI/CurrentTrackMetaData the track item uri and the corresponding metadata.

I’ve started to add that functionality to the Coherence MediaServers and to the GStreamer MediaRenderer.
It will be part of the upcoming 0.6.4 release of Coherence and the 0.2.2 release of the UPnP-Inspector.

As the specification doesn’t describe the whole thing in detail and I haven’t seen yet an UPnP A/V MediaServer beside Coherence supporting this I’m glad about any feedback.


  • Hi,

    Interesting post. I recently picked up a DLNA-capable receiver hoping to use it for music streaming. I’ve got a Linux box as a server and an iPhone i was hoping to use as a remote/control point. Sadly, the DLNA remote software for iPhone is generally pretty awful, and even the best of the bunch are incapable of keeping the music going after the phone is shut down. I guess the software has to tell the receiver to play each song one at a time, rather than telling it to play the whole album. It sounds like you’re describing the solution to this problem and I’m wondering if my device is capable of supporting playcontainers. Is there any way for me to find out? I’m totally comfortable with hacking python and I’ve already dumped the device & service description xml files from the receiver.


    Comment by Nathan — Aug 24, 2011 8:50:39 AM | #