= Upmpdcli and the Cloud == Introduction upmpdcli is initially a UPnP Media Renderer device: it receives music descriptors, and downloads and plays what it is requested to play (or more precisely, tells MPD to play it). As standard with UPnP, this is done in conjunction with a Control Point, with which the user interacts, and a Media Server, which stores the music and exports catalog and audio data. The Control Point browses the music catalog offered by the Media Server, and tells upmpdcli/mpd what to play. The Renderer then talks directly to the Media Server to download the audio data. This approach presents a difficulty for integrating a streaming service such as Tidal, Qobuz, or Google Play Music: they require authentication, and only provide temporary URLs for downloading (these URLs can't sit in a playlist in the Renderer, they would expire). Using a "natural" approach where the Control Point would browse the service, and the Renderer access its data, there would be two devices which would need to know about the details of the streaming service authentication and security: the Control Point and the Renderer, probably needing, in addition, more communication between the two than was standardized by UPnP. There is a relatively simple solution to this problem, which is to design a Media Server to act as a gateway to the services. The Media Server deals with authentication, presents the service assets inside a browsable and possibly searchable tree, and exports stable URLs to the local network Renderers. When the data is actually requested, the Media Server manages to provide it, which can be handled by an HTTP redirection to the freshly translated service URL, or by actually proxying the data stream. There are some potential reasons to closely associate such a Media Server to a Control Point (a solution adopted by a very well known Android Control Point), or to the Renderer itself, which is the approach chosen for upmpdcli. In practise though, it was found that a standalone Media Server works. The upmpdcli Media Server can provide access to any local Media Renderer (upmpdcli-based or not), not only to its upmpdcli instance. The current implementation supports Google Music, Qobuz and Tidal, and would be easy to extend for other cloud services. This only works for users who have a valid subscription for the service they want to access. The Media Server uses the services' WEB APIs which are in general not officially supported, so that any service could stop working at any moment if the supplier decides that they want to close access. == Implementation The Media Server was initially implemented as an embedded UPnP device inside the Renderer device. This was found to confuse many Control Points, so that the default approach is now to have the Media Server as a separate root device (running inside a separate process because of libupnp limitations). The Media Server device will be created if the configuration file has set parameters for any of the supported services. See the link:upmpdcli.html#upmpdcli.configfile[configuration documentation] for details (look for your service name).