= 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).

== Installation and service-specific notes

The code for accessing most services is self-contained. There is an

exception for Google Music, which needs the separate installation of a

Python library.

=== Google Music

You need to install the

link:http://unofficial-google-music-api.readthedocs.io/en/latest/usage.html#usage[gmusicapi Python Package]

=== Tidal

Nothing for now.

=== Qobuz

Nothing for now.