There are two different approaches for integrating MPD in an UPnP context. They are very different, it makes no sense to use both, and they are often confused anyway. Here follows a tentative explanation.

Pure MPD (no UPnP)

By default, MPD accesses audio data through a file-level protocol, either reading from the local file system, or from a network disk shared through NFS or Windows sharing (SMB).

You tell MPD where the data is by setting a directory path in the MPD configuration file (e.g. music_directory "/home/me/MyMusic".

There are also standard plugins for fetching data in other ways, mostly used for internet radios. One of them, which I’ll mention because it is used by the UPnP integration solutions, is the curl plugin, used for fetching data through HTTP (the WEB protocol).

MPD manages its own tags catalog, which it builds from metadata extracted from the audio files.

You browse the catalog and control playing with an MPD client, which uses an MPD-specific protocol to talk to the mpd daemon. There are many clients, from Linux command-line ones, to GUIs, to WEB/PHP based ones.

Why would you want to change this ?

The main possible reasons:

  • You want to use an UPnP control point for browsing and playing music, because you are used to it, because you use it for other things, or because you just prefer it to native MPD clients.

  • Your audio data is stored on an UPnP Media Server, you took a lot of care to organize the tags, and you don’t like the way the MPD database is organized.

  • You have / want several music players, and duplicating the catalog on each of them seems wasteful (which would happen with multiple MPD instances in their default configuration).

  • Your media server does not have a file-level interface (unlikely), so you can’t use bare MPD with it. Or you just don’t want to set it up.

There are two approaches to insert MPD in an UPnP context. They are very different, but from the user point of view, the only question which matters is:

  • Do you want to use an MPD client (e.g. MPDroid, Cantata, etc.) to control the playing, or an UPnP one (e.g. Bubble UPnP, PlugPlayer, Lumin, etc.) ?

If you want an MPD client, you will choose the mpd-upnp approach (back-end integration)

If you want an UPnP Control Point, you will choose the front-end one.

Both solutions are described in more detail below. Note that once you’ve decided the kind of control software that you want to use, there is no real need for more details: just go install the right one.

Front-end integration: upmpdcli, MediaPlayer

These are applications which sit in front of MPD. Upmpdcli is C++, MediaPlayer is Java, they both do mostly the same things, the choice is largely about which will be easier to install on your particular Linux distribution.

Both present a standard UPnP/DLNA/OpenHome interface to the network, and are usable with most UPnP Control Points.

They talk the MPD client protocol behind the scenes to control actual music playing.

Your UPnP Control Point (your user interface) directly browses catalog data from an UPnP Media Server (e.g. Minim Server, MiniDlna, Asset, Twonky, etc.), and tells upmpdcli or MediaPlayer what to play. upmpdcli/MediaPlayer then controls MPD, which fetches the audio data through an HTTP URL (pointing to the Media Server).

MPD remains directly usable from an MPD client. It could also manage local audio data and a catalog, even if this does not make much sense.

Back-end integration: mpd-upnp

This is implemented as an MPD Database plugin. Instead of reading files and building its own catalog, MPD accesses an UPnP Media Server both for tag and audio data. Tags are accessed through UPnP, and data is retrieved through HTTP.

MPD then translates the UPnP catalog data to the native MPD client protocol, so that MPD clients think that they are talking to a normal MPD (but instead they are browsing the UPnP Media Server through MPD).

In this configuration, MPD can’t manage local data and tags. The file and UPnP database plugins are mutually exclusive.