what is streaming my Qobuz?

[Mark Dirac]

I've got Qobuz playing wonderfully from BubbleUPnP on a tablet to a RPi Allo DigiOne Sig. Thanks Moode.

But I suspect I am not using it "properly"?

If I add my Qobuz credentials to BubbleUPnP on the tablet, it works. If instead I add my Qobuz credentials to Moode on the Rpi streamer, it doesn't work.

I suspect that it is the tablet/Bubble which is pulling the stream from Qobuz (and then passing it to Moode/RPi to render), rather than Moode/Allo pulling down the Qobuz directly. Is this the case please?

I can find no way in BubbleUPnP to instruct Moode instead to pull down the Qobuz stream.  What may be wrong here please? How is it intended that I should use Moode's Qobuz login capability?

[SoundAdikt]

It's no longer supported due to Qobuz requiring a unique and private app ID and secret ID: these as I understand are only issued to official developers and manufacturers. It still works on some devices by using old app and secret IDs that were previously used in the public domain but have not yet been blocked by Qobuz, or, they are legitimate ones... Personally, I use BubbleUPnP Server which enables Qobuz to be directly used on Moode, ie. I can use a UPnP control point (such as Linn Kazoo) and play tracks that are streamed directly from Qobuz to Moode.

[Mark Dirac]

It's no longer supported due to Qobuz requiring a unique and private app ID and secret ID: these as I understand are only issued to official developers and manufacturers.  It still works on some devices by using old app and secret IDs that were previously used in the public domain but have not yet been blocked by Qobuz, or, they are legitimate ones...  Personally, I use BubbleUPnP Server which enables Qobuz to be directly used on Moode, ie. I can use a UPnP control point (such as Linn Kazoo) and play tracks that are streamed directly from Qobuz to Moode.

Thanks for that SA. After much searching, here are some key posts over at
https://audiophilestyle.com/forums/topic...nt=1094317  (And SA's post here is a great summary.)

You say "streamed directly from Qobuz to Moode."  My understand is that, as you say, Moode is no longer allowed a key to draw down directly from Qobuz. I reckon that BubbleUPnP Server is proxying and resending a stream indirectly to Moode only for rendering? Please would you mind confirming?

[Mark Dirac]

It's no longer supported due to Qobuz requiring a unique and private app ID and secret ID

For the record, and to minimise fake news, Qobuz is streaming very well directly to Moode on my Allo USBridge controlled by BubbleUPnP, as suggested by SoundAdikt. The stream does not pass though my tablet.

(Bubble UPnP authenticates my Qobuz password, and validates Moode's (actually, UpMPDcli's) request to draw the stream from Qobuz.)

[Nessuno]

For the record, and to minimise fake news, Qobuz is streaming very well directly to Moode on my Allo USBridge controlled by BubbleUPnP, as suggested by SoundAdikt. The stream does not pass though my tablet.

(Bubble UPnP authenticates my Qobuz password, and validates Moode's (actually, UpMPDcli's) request to draw the stream from Qobuz.)

True, but without a BubbleUPNP server on the way, the controller app is the unique owner of the current playlist and must connect to Moode at the start of each track, while if a BubbleUPNP server is running alongside Moode, it becomes the playlist owner so that every controller on the same network can share and manage it, but needs not to have the app running all the time for the playlist to be consumed (recent Android phones like my Huawei puts aggressively to doze apps not in foreground, to save battey life).

[TheOldPresbyope]

It's no longer supported due to Qobuz requiring a unique and private app ID and secret ID

For the record, and to minimise fake news, Qobuz is streaming very well directly to Moode on my Allo USBridge controlled by BubbleUPnP, as suggested by SoundAdikt. The stream does not pass though my tablet.

(Bubble UPnP authenticates my Qobuz password, and validates Moode's (actually, UpMPDcli's) request to draw the stream from Qobuz.)

True, but to maximize real news, Qobuz, like Tidal before it, has been making it more and more difficult for FOSS developers to keep their plugins working.

Here's a year-old news item from the upmpdcli website

2019-10-06Qobuz access was revoked: If you were using Qobuz and it's not working any more, don't pull your hair, the Qobuz plugin stopped working (either through the Media Server or with OHCredentials). Qobuz revoked the app_id, and also deleted the API documentation on Github. If you are a hardware integrator/manufacturer using upmpdcli to support Qobuz access (I know there are some), I made a modification to the Qobuz plugin so that the app_id/secret can be stored externally instead of being embedded in the source. This means that, if you can convince Qobuz to supply you with the appropriate pair, you can easily restore function, without having to support a modified module. Of course, this supposes that the API itself does not change.

More recently, a clever hack from another developer restored the Qobuz plugin functionality

2020-12-08Version 1.5.5. Fix initial issues in 1.5.2. See the release notes. Note: Tidal access does not work any more at all. Qobuz access works through the media server, not through the Kazoo or Lumin login (OpenHome Credentials).

Essentially, the upmpdcli media server Qobuz plugin tells the Qobuz servers it is the Qobuz web client.

That's working for now, but my guess is it won't work forever.


Most if not all the music streaming services have moved to oauth2.0 authentication service. One now needs three things to stream from their service:

1. A stable API to write code against. If one is lucky this API is published. As seen above, Qobuz deleted their documentation so hackers had to reverse-engineer the API by packet-sniffing while running official Qobuz apps. The streaming service can change its API without notice.
   
2. Authentication of the client app. This means the developer registers the app (upmpdcli and its Qobuz plugin in our case) with the service and receives an app ID and app "secret". FOSS developers haven't been able to register their apps so they play "button, button, who's got the button", again through packet sniffing. This is where games like masquerading as the web client come into play. When the streaming service gets annoyed, it invalidates the particular ID/secret pair in their authentication server. As far as I know, no FOSS developer has ever received a "cease and desist" letter from a service's lawyer, but it could yet happen.
   
3. Authorization by the user for the registered client app to access the service. Here's where one signs into the app with account username/password. By its very nature, this should always work if the user credentials are legit.
   

Regards,
Kent

[the_bertrum]

This seems to be counter-productive to me. On one hand these services are saying "give me your money because we let you stream music at resolutions higher than your ear can detect" and on the other they say "you must use a device that negates any benefit you might get from such resolution".

You may detect from my cynical tone, that I don't subscribe to any of these hi-res services but I'm intrigued by their conflict between making the files available while also keeping them secure.