None
open
nobody
None
2019-11-11
2019-10-05
Anonymous
No

Login to Qobuz doesn't work anymore. According to these related issues:

https://github.com/tidalf/plugin.audio.qobuz/issues/247
https://forum.volumio.org/qobuz-temporarily-not-working-from-t12936.html

"They decided to revoke the API key and issue a new one, in order to allow only updated Volumio clients to access their service."

Upmpdcli seems to be affected by this issue, too. I use Upmpdcli with Kazoo.

I am running these versions: Upmpdcli 1.4.2, libupnpp 0.17.1

Discussion

1 2 > >> (Page 1 of 2)
  • Anonymous
    Anonymous
    2019-10-07

    Apparently upmpdcli also uses the revoked Kodi's Qobuz credentials (which would break upmpdcli's OHCredentials service support for Qobuz), according to bubbleguuum (BubbleUPnP's developer):
    https://audiophilestyle.com/forums/topic/27851-sonicorbiter-tidalqobuz/?do=findComment&comment=994737

    Would it be possible for the developer to apply to Qobuz for upmpdcli to have its own Qobuz API credentials?

     
    Last edit: Anonymous 2019-10-07
  • medoc
    medoc
    2019-10-07

    Hi,

    I'm not really motivated to get in touch with Qobuz, the contact to use is not obvious and they removed the API docs, so I guess that they don't want to be bothered.

    I'll wait to see if they do anything for Kodi.

     
  • Anonymous
    Anonymous
    2019-10-08

    At least they (qobuz) worked together with Volumio to solve the problem, from the linked thread:

    “After a 4 days long exchange with QOBUZ technical team there is finally a solution, although not the one we were hoping for.
    They decided to revoke the API key and issue a new one, in order to allow only updated Volumio clients to access their service.”

     
  • medoc
    medoc
    2019-10-08

    The Volumio appid/key does not come with the distribution, you must have a payed subscription. I guess that they have some way to dispatch the data as needed.

    Volumio has gone full commercial, and there are aspects of the system which are not open source any more as far as I can see.

    I have no way and, really, no inclination, to do this with upmpdcli.

    It does not make sense for me to request an app_id/secret pair because I can't hide it, so it will always be possible to use it for a stream ripper.

    I pushed a small change to the Qobuz module to make it easy to store the values externally (they were previously directly in the source code). This will allow hardware integrators to request a pair from Qobuz and set it up. It is much easier to at least somewhat hide the values in a hardware box, for example inside a binary closed-source program, than when they are for all to see on Github.

    If Qobuz are that concerned with stream rippers, it does not make sense for them to provide any open source app with general access. So it's the end for DYI boxes directly streaming Qobuz, you have to go through an approved application with the ability to hide its secret (e.g. bubbleupnp or a hardware streamer). This does not change the audio quality as the streams themselves are still direct.

    Continued support in upmpdcli will of course suppose that the API as it was documented on Github does not change.

     
  • medoc
    medoc
    2019-10-08

    • status: open --> closed
    • milestone: -->
     
  • medoc
    medoc
    2019-10-11

    • status: closed --> open
     
  • medoc
    medoc
    2019-11-01

    • status: open --> closed
     
  • Anonymous
    Anonymous
    2019-11-10

    An alternative seems to be using BubbleUPnP Server to create a proxy for each upmpdcli renderer. If you set "openhome = 0", the original renderer becomes invisible in OpenHome Control points. Selecting the proxy lets you access Qobuz AND do most of the things you used to be able to do.

    Unfortunately, this disables

    • Internet Radio support
    • Songcast support

    It would be nice if it were possible to retain those functions, while still being able to use BubbleUPnP Server to proxy the Qobuz connection.

     
  • medoc
    medoc
    2019-11-11

    • status: closed --> open
     
  • medoc
    medoc
    2019-11-11

    Internet radio and Songcast are openhome services, so if you shut down openhome, you lose them.
    I don't think that the two could be separated.

    There might be a way around this if bubble server ignored the openhome functions and managed the renderer as UPnP/AV, but I think that there is little chance that this would work well because UPnP/AV renderers are single access, so that bubble server expects exclusive use of the device, and an alternative access through openhome (for radio) would probably be in conflict.

    I think that the best approach for using Qobuz with upmpdcli is to go through the Bubble UPnP control point, but of course, this supposes that you use android and like bubble as a CP.

     
1 2 > >> (Page 1 of 2)

Cancel   Add attachment