• medoc
    medoc
    2018-04-26

    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.