MPD now has a database plugin which makes it possible to browse and play music stored on an UPnP Media Server.

The main function of the plugin is to let you use an MPD client to browse an UPnP Media Server, and play music from it. If you would want to use an UPnP client (Control Point) instead, this is not what you want. See a description of the alternative approaches here.

I initially wrote the code, and it is now included in the MPD git source.

The capability is now released as part of MPD 0.19 (as long as it is configured with --enable-upnp). I see no reason to use the actual software pointed from this page, which is only of archival interest. The explanations about what this is good for could still be useful though

Basic flow

I have tested the solution with a mix of UPnP servers:

  • MiniDLNA

  • MediaTomb

  • Twonky

  • Whatever runs in a D-Link NAS

And also a variety of MPD clients.

As far as I can see, everything that makes sense works properly. Of course, it is still possible that using different clients and servers may shake the plugin in new ways and uncover bugs, so, if you try this, I would very much appreciate feedback:, or use the new comments system.

What’s the point ?

When running multiple MPDs on a network with a central file/media server, it is wasteful and error-prone to have every daemon update a local tag database.

Delegating this part to the central server is better because only local disk accesses are needed then.

This can be done either with running MPD on the server and the MPD Proxy Database plugin on the clients, or with an UPnP/DLNA server and the MPD UPnP database plugin on the clients.

Using UPnP to talk to the file server(s) has several advantages:

  • The MPD player will be able to see all the UPnP servers on the network (MPD-to- MPD is limited to one server).

  • Non-MPD player devices are able to access the music too.

  • MPD may not be available on your server network appliance device. OTOH, almost all implement UPnP.

  • Media center software like XBMC also have UPnP Media Server capability, so they will be accessible.

  • UPnP is for video too. By using it for audio storage, you can have a single software package for distributing audio and video.

Why would you want to run MPD on the client then, instead of an UPnP media renderer ?

  • There are very few media renderer packages for Linux (I actually know of only one).

  • MPD has been there for long and is very stable. It just works.

  • MPD is thoroughly and fully open source (not the I’m commercial but you can see the source if you really want kind).

  • MPD has tons of cool clients, one of them you may be familiar with and want to keep.

In any case, it’s better to have more options !


Speaking of choice, there is also now an UPnP front-end for MPD. This is a different approach to MPD-UPnP integration than what is presented on this page (and you can’t use both). It allows you to integrate MPD in a UPnP context by using it as a pure media renderer (using UPnP software for the control point, not an MPD client). To each his own !

MPD-UPNP versions

The code for the UPNP plugin has been modified/integrated into the MPD release 19. Parts of the following text may still be of interest (or not…).

Retrieving the source code for the original patch

The plugin exists in a github repository. To check it out:

git clone mpd-upnp
cd mpd-upnp
git checkout -b upnp origin/upnp

I also have Debian/Ubuntu packaging set up, so I can easily provide packages for these systems for testing. If you would like to try the software but have trouble with building from source, just contact me:

Also, as the Raspberry Pi is a particularly interesting platform for this system (a small dataless music player hooked behind your stereo !), we have a pre-built raspbian package, which is trivial to install.

Raspbian packages (original modification over mpd 0.18)

If you are installing Raspbian/MPD from scratch for testing this, you may find a description of a possible procedure useful (or not…).

Binary and source packages for the Rasberry Pi running raspbian (updated around 2013-11-15 if this matters).

This is not a full Debian package repository, and you will have to install the dependancies "by hand" from the official Raspbian repository (see below).

To install:

  • Download mpd_0.18.2upnp45bc0_armhf.deb

  • Deinstall the standard mpd if it’s already there:

    sudo apt-get remove mpd
  • Install the dependancies (these are mostly the same as the ones for a standard mpd, so it’s quite possible that almost all are already there):

    sudo  apt-get install \
      libadplug-2.2.1-0 libao4 libaudiofile1 libavcodec53 libavformat53 \
      libavutil51 libfaad2 libfluidsynth1 libgme0 libiso9660-8 \
      libmms0 libmodplug1 libmpcdec6 libmpdclient2 libmpg123-0 \
      libopenal1 libopus0 libresid-builder0c2a libroar2 \
      libshout3 libsidplay2 libsidutils0 \
      libsystemd-daemon0 libupnp6 libwavpack1 libwildmidi1 libyajl2
  • Install mpd:

    sudo dpkg -i mpd_0.18.2upnp45bc0_armhf.deb

Then adjust the configuration file (see below).

To restore the standard mpd:

sudo dpkg -r mpd
sudo apt-get install mpd

And comment out the database section of the configuration file.

Building from source

The plugin is based on libupnp 1.6

For mysterious reasons, the appropriate package is named libupnp3 on Ubuntu older than Raring, libupnp6 on Debian and more recent Ubuntu. I have not looked up the package names for all distributions, but it seems to be named libupnp-devel on Fedora.

You will also need libexpat (deb: libexpat1-dev rpm: expat-devel)

So, beyond the usual packages used to build mpd you will need:

On Debian and recent Ubuntu

sudo apt-get install libupnp6-dev libexpat1-dev

On older Ubuntu (e.g.: precise):

sudo apt-get install libupnp3-dev libexpat1-dev

On Fedora

sudo yum install libupnp-devel expat-devel

Then practise the usual invocations for building:

./configure --prefix=/usr --enable-upnp --enable-curl [other mpd config options]
sudo make install

On some older Ubuntu versions (12.04 Precise included), the pkg-config data is missing for libexpat, and this causes an error during the configure command above. The solution is to create the pkgconfig files:

For 64 Bits systems, add a file named /usr/lib/x86_64-linux-gnu/pkgconfig/expat.pc:


Name: expat
Version: 2.1.0
Description: expat XML parser
Libs: -L${libdir} -lexpat
Cflags: -I${includedir}

For 32 bits systems, int /usr/lib/i386-linux-gnu/pkgconfig/expat.pc:


Name: expat
Version: 2.1.0
Description: expat XML parser
Libs: -L${libdir} -lexpat
Cflags: -I${includedir}

Configuration file


database {
    plugin "upnp"

You can also comment out db_file but some init scripts don’t like this.

Trying it out

For diagnostics, during development I usually run mpd as follows, to easily see the log messages:

sudo ./src/mpd --no-daemon --stderr --verbose [config file name]

Otherwise, you can just run mpd normally.

Once mpd is running, your client should see a list of the network Media Servers as the top level directory.

Under the top level, you will see the hierarchy chosen by the type of Media Server, which usually has little to do with the file tree (so this is quite different from the usual MPD).

Note that you should always follow the Browse by Folder options from the MPD client (these can have various names depending on the MPD client). Options to browse by artist or album, as provided by MPD will not work. You will find equivalent lists inside the tree shown by the UPnP server.

UPnP servers do not expose functionality which could be used to implement the direct tag-based browsing offered by an MPD server.

This sounds complicated, but just try it and it should become clear soon enough.

The rest is supposed to work as usual.

Please note that some Media Servers (MediaTomb for example) do not support searching, just browsing/playing.

If you want to try with a full-featured server, MiniDLNA is a good candidate. Twonky is good too but not free. I have also tested with the Media Server which comes with D-Link NAS boxes, and it works, but it is so slow that it sometimes triggers timeouts with some MPD clients (e.g. gmpc).


Known issues

Loading playlists should work, but saving them probably won’t.

Recursive directory add does not work fully: the depth is limited to 1, so this is ok to add an album directory, but it won’t go further.

Things based on VisitUniqueTags, like requesting all genres, or all artists, does not work, so the metadata browsers in most clients do not work. UPnP just does not work like this. Browse the database tree instead: it will usually have a directory with all the artists, one with the albums, the genres.

There is a fundamental difference about track identifiers between MPD and UPnP. As far as I understand, for MPD, the pathname is the fundamental identifier. This is not the case at all for UPnP, where a given track will be seen under several pathnames in the virtual tree, and objects are identified by an arbitrary unique Id.

The MPD plugin synthetizes paths based on track or container title attributes, but this means that a directory can contain apparently identical paths (if several entries have the same title).

There could be ways around this (the title could be made unique in some way), but I did not pursue them. Simply adding other fields may not be enough, so this would have to be based on the object id, or some other arbitrary value.

The consequences are mostly for searching. The normal pathnames are mostly useless as search results (typically a search for "Satisfaction" may have the UPnP server respond with entries under "All Music", all with the same title).

In this situation the MPD plugin choses to respond with arbitrary and recognizable paths based on the object ID, but clients which directly display them end up showing garbage. Happily enough most clients retrieve the object attributes for display, which works fine. Notably, phpmp does not.

Some of these issues could be improved if it appeared that the plugin was actually of use.

Another practical issue is that MPD daemonizing does not play well with whatever libupnp does, which means that the library initialization has to be delayed until later, causing a 2 S delay on the first client access.


All clients

Functions based on browsing Metadata retrieved through VisitUniqueTags (artists/albums/genres…) do not work. Only searching or exploring the "directory" tree works. As the latter contains "Artists", "Albums" etc. directory, there is no functional consequence, but it may cause problems in the interface.


Works normally, except for "list" as noted above.


When adding tracks resulting from a search, the labels displayed in the playlist are the download URLs, not the titles. Otherwise works fine


Works fine. The timeouts are too short for some low-end NAS Media Servers AND for twonky search which is horribly slow when there are many tracks. A timeout will usually crash the client, so this basically does not work with twonky (gmpc performs searches for albums all the time).


Works fine.

Droid MPD and MPDroid



comments powered by Disqus