Open Source Projects Europe

Isn't this just an update to the existing optional OpenHome Streaming Services? So not exactly new, just not supported by upmpdcli.

Shouldn't the question actually be to ask why the developer felt it necessary for upmpdcli to have its own access to TIDAL & Qobuz (via the upmpdcli Media Server), rather than provide TIDAL & Qobuz access by supporting the 'official' OpenHome Streaming Services?

About streaming services implementation:

The OpenHome approach divides the function between the control point and the renderer. This implies that only a few compatible Control Points can access the streaming services, and a need for secure communication (cryptography) between CP and Renderer. This is complicated and I fail to see the benefits, except possibly better browsing (at the cost of a service-specific browser in the CP).

Upmpdcli implements access to the streaming services by emulating a standard UPnP Media Server interface. The consequence is that the Control Point is not even aware that it accesses a streaming service, it only sees a regular Content Directory. ANY UPnP AV or OpenHome CP can stream stuff from Tidal. As far as I can see, and until someone lights my lantern, the only problem with this is that the credentials have to be set on the Media Server, by editing a file for a bare upmpdcli install, but I think that Moode for example has a GUI for it (in any case, it's a point of detail). IMHO, this is just a superior approach, I fail to see any significant advantage to the OpenHome way.

As a bit of news, Qobuz is rolling out an UPnP output for their app (still very buggy at this moment), so this is going to be an obsolete question anyway (we can organize bets for how much time it takes until Tidal does the same 5 4 3..).

I'm not too sure of what the problem is with Lumin/favourites, I'd need more specific info. I'm a bit surprised that this would be an Eriskay issue though, I had understood that this was still very much experimental.

About Eriskay:

I am not committed one way or another, but at this moment, I also fail to see the point, this is change for change. Dumping DIDL for a proprietary metadata format ??? Weird (it's XML, just extend it). What does Eriskay really bring as new user-level functions ? If it becomes necessary to support Eriskay, I'll do it though.

Favourites: I had not understood that this was the Tidal favourites, not some local thing. So yes, this would be an advantage of the OpenHome solution: the CP knows about the service API, so it can do this.

About the Qqobuz app: it keeps control of the playlist, so there is no need for the renderer to know the API or have tokens, it just gets one direct URI at a time (using AVTransport, not OpenHome Playlist). Inconvenient of course, the usual one with AVTransport: the CP must be awake to keep the list playing.

Understand that this is a subject of discussion for me, I find it interesting and I had not thought of the service favourites issue when I answered. Actually my main objection to implementing the Credentials service is that I'd need to link upmpdcli with a crypto lib (big dependancy etc.). Otherwise, I could just do it even while thinking that it's not the best approach, and the users could just decide what to use. So it's still a maybe.

I am not sure of how Bubble works when talking to a 'real' Linn or Lumin renderer. But when talking to upmpdcli, it just proxies the Qobuz URL, by implementing a local HTTP server. This is mostly the same as what upmpdcli does, an all-in-one solution, but implemented in the CP, not in the media server. Advantage: the CP can be more clever (adding favourites etc.), inconvenient: it needs to be awake for anything to play.

Eriskay: yep, I think that this has nothing to do with eriskay.

I actually just wrote an implementation of the Credentials service, executing an openssl command to do the decrypting to avoid a permanent dependancy. Did it mostly for the fun of seeing how far I could go. Things work for browsing in Kazoo, up to the point where tracks are added. The problem there is that upmpdcli (the renderer) does not manage the Playlist: mpd does, and of course, mpd knows nothing about translating the permanent URIs into the temporary media ones which allow actually fetching the stream. So I'd need to either implement a proxy, mostly reusing the code from the media server implementation, or manage the playlist inside upmpdcli, or just drop the idea. I am going to let it rest a bit.

Hi,

I now have something which seems to work, at least for qobuz (my tidal subscription has expired). It probably works with tidal too.

You need to checkout the ohcredentials branch. /etc/upmpdcli.conf should have a "qobuzautostart=1" entry (or "tidalautostart=1")

Kazoo should then be able to do its stuff...

• status: open --> closed
• milestone: -->

Closing this as the title is confusing and the heart of the matter has been addressed by the ohcredentials implementation.