Official Qobuz Issues Thread

[Cebolla]

1 hour ago, The Computer Audiophile said:

Welcome to the world of UPnP, the most nonstandard standard in the audio world. 

 

It's to do with how the app directs the audio file player to stream the audio file tracks from Qobuz's online server over http, rather than anything to do UPnP.

[Cebolla]

2 hours ago, deho said:

After months of trials to use mConnect Player HD and despite the latest update 3.3.25,  I still have problems when streaming Qobuz (or Tidal) HiRes files to my Technics SU-R1 network player.

• drop-outs and lags with HiRes files from Qobuz or Tidal, it works seamlessly with standard resolution files 
• the network connections do not appear to be the culprit since I have a stable high internet throughput of average 80-100Mb/s and all the system is connected through a gigabit LAN + wifi routed through a Synology Router RT2600ac
• the Technics SU-R1 network player buffer capacity doesn’t appear either to be the culprit since streaming Qobuz or Tidal HiRes file works seamlessly after installing BubbleUpNp on my Synology NAS and using on my iPad an OpenHome compatible control application like Lumin or Linn Kazoo.

 

  

2 hours ago, deho said:

I'm quite surprised since it works well with other OpenHome applications. Does mConnect make some treatment to the streamed audio files which increase their size ???

 

The difference is the mconnect Player controller app gets SU-R1 to stream the audio file tracks directly from Qobuz online server, whereas the BubbleUPnP Server proxies the audio file tracks for the SU-R1 when you are using the OpenHome controller apps, so the SU-R1 is streaming the audio file tracks indirectly from Qobuz's online server, ie, via your Synology NAS.

 

If anything, depending on how you've configured it, the BubbleUPnP Server could be doing something to the file tracks.The mconnect Player controller most definitely does not handle the audio file tracks.

 

 

  

2 hours ago, deho said:

After having contacted Technics products support, they made some trials with mConnect and answered me (I quote them) : " the quantity of datas sent by the mConnect App to the network player is very significant and overload its the capacity, which then provoke lags or abandon of the reading."

 

No idea what Technics support were testing if by "the quantity of datas sent by the mconnect App to the network player" they were talking about the audio file track data. I repeat, the audio file track data would come directly from Qobuz's online server to the network player and most definitely not via the mconnect Player controller app.

 

[Cebolla]

1 hour ago, The Computer Audiophile said:

Huh?

 

1 hour ago, deho said:

I also suspect something like that, but it's only problematic with mConnect and UPNP, not with OpenHome ... Your point of view is quite interesting ! Can you develop it ?

Thank you in advance.

 

It's not really anything to do with UPnP or OpenHome as such, but how the the network player streams the audio file data. as an http client, from the http server that the audio file tracks are originally being supplied from, ie, Qobuz's online server:

 

- The mconnect Player app supplies the network player with the audio file track URLs that resolve (directly) to Qobuz's online server;

- The BubbleUPnP Server's create an OpenHome renderer function supplies the network player with audio file track URLs that resolve to its own (proxy) http server. It is the BubbleUPnP Server that is actually fetching the file tracks directly from Qobuz's online server, so it is buffering them for the network player.

 

Note: the BubbleUPnP Server's create an OpenHome renderer function 'tricks' the OpenHome controllers into controlling it as the OpenHome renderer, not the associated network player the OpenHome renderer was created for. The BubbleUPnP Server translates the OpenHome controller commands into standard UPnP controller commands, which it then sends to the associated network player - so the network player is still being controlled by a UPnP controller, albeit the BubbleUPnP Server's own private internal one!

Also, bear in mind true OpenHome network players, like those made by Linn and Lumin, also stream the audio file tracks directly from Qobuz's online server.

 

 

It looks like Technics SU-R1 is ok when receiving Qobuz's hi-res audio file tracks when they are being buffered by the BubbleUPnP Server running on your Synology NAS, but has problems when receiving them directly from Qobuz's online server.

 

It's possible that the buffering of the audio file tracks by the BubbleUPnP Server on its own is what is helping the SU-R1 or, as I mentioned in my last post, the BubbleUPnP Server may be set (in its Advanced settings) to alter the hi-res file track data itself by transcoding to a lower sample rate and/or bit depth and this is what is actually helping it.

[Cebolla]

  

1 hour ago, The Computer Audiophile said:

Doesn’t this have everything to do with how UPnP works, in that it doesn’t set actual standards? Roon’s RAAT doesn’t have this issue, neither do USB connected devices. It’s a protocol thing and UPnP is the Wild West. 

 

Qobuz access is not in the standard UPnP spec, but being an open standard it doesn't prevent you from bolting on Qobuz access onto a UPnP controller, if that's what you're getting at.

 

RAAT in itself doesn't support Qobuz, as it is being spoon fed all of its audio by the Roon Core Server's built-in player's output - if the Roon Core Server had a bug streaming from Qobuz's online server, you'd soon know about it (same goes for the computer player software with Qobuz streaming capabilities outputting its audio to devices connected to it by USB audio)!

[Cebolla]

15 minutes ago, MikeyFresh said:

Not sure how much this adds to the conversation, but I can stream Qobuz with zero issues using either Mconnect, or BubbleUPnP, to either a Sonore microRendu, or Raspberry Pi running Moode's UPnP Renderer. In the case of Mconnect, that can be either the Android or iOS version of that app, same result (BubbleUPnP is Android only).

 

There does not appear from an end-user standpoint to be any difference at all in using those two apps streaming Qobuz to those two Renderers, why a Technics Renderer would be significantly different is anyone's guess then.

 

I do have BubbleUPnP Server running in the background 24/7 on a Mac mini, but it is not set-up to create any Open Home Renderers to the best of my recollection.

 

I believe if you are using the BubbpleUPnP Android app in tandem with the BubbleUPnP Server, then the BubbleUPnP Server automatically proxies all of the online music service streams that are being played by the UPnP renderer under the control of the BubbleUPnP Android app, regardless of an OpenHome renderer having been created for the UPnP renderer or not.

 

So I agree, by using those two controller apps you are to getting those two renderers to stream from Qobuz in the same alternative ways as the Technics is, so both directly and via the BubbleUPnP Server.

[Cebolla]

3 hours ago, deho said:

Thank you David ... I thought it has disappeared with an update. I restored it and it works without lags which tend to demonstrate that the Technics is indeed technically able to stream by himself Hi-Res files directly from Qobuz.

 

You've made an assumption that the Qobuz app for PC through its UPnP/DLNA function is getting the Technics to stream the audio file tracks directly from Qobuz's online server. This may not be the case, as the audio file tracks may instead be being streamed by the Qobuz app for PC from the Qobuz online server first and then passed onto the Technics, so similar to your BubbleUPnP Server setup.

 

@David Craff has previously commented over a year ago that some network players are having problems streaming the audio file tracks directly from Qobuz's online server and that they were proposing to change the UPnP/DLNA function to get the tracks to be proxied instead:

 

 

Perhaps David can clarify this?

[Cebolla]

Apologies, I've edited my last post in the middle of you replying, with further info that I've now found that I couldn't quite remember when I first typed!

 

If Qobuz did implement the proposed change, then it would certainly be the case. Of special interest as far as the Technics network player is concerned is David had mentioned the reason for the proposed change appears to be that Qobuz had noticed that some network players had problems directly streaming the audio file tracks from the Qobuz online server.

[Cebolla]

5 hours ago, clipper said:

It stutters and skips for me too.  That track on Tidal is fine.  Just need a re-rip, I guess...

 

Good album...

 

Interesting that you say the TIDAL version is fine. I actually found two versions of the same album on TIDAL (UK account):

https://listen.tidal.com/album/19129698 - track 21 seems to be ok;

https://listen.tidal.com/album/111593186 - track 21 sounds exactly as it does on Qobuz!

 

[Cebolla]

Agreed, the term is audio resolution, not bitrate. Plus the pedant in me insists on the bit & kHz symbols being placed beside the appropriate values for completeness. 😀

 

Talking about bitrate - why should playback displays even bother mentioning it for lossless audio files, anyway?

Certainly not the uncompressed bitrate, if compressed lossless audio files are being network streamed, in the case of network bandwidth use being of interest in a streamer.

[Cebolla]

  

3 hours ago, Richard Dale said:

OK, thanks. I don't want to use a VPN but I expect to login with my username and password in the UK. I wouldn't expect my subscription to fully work in somewhere like the USA, because of the very different copyright regime to Spain, but I was hoping that different parts of Europe would have a more compatible copyright regime.

 

The UK's always been different to the rest of the EU with regards music industry copyright and the uncertainty surrounding Brexit (remember that?) doesn't help.

[Cebolla]

1 hour ago, Mike48 said:

Is it Qobuz's intention to get DLNA working? I tried it from the Windows Quobuz application to two different DLNA renderers that work perfectly with other devices on my home network. In neither case was Qobuz able to play music through the renderers.

P.S. Readers, please do not tell me to get Roon. I know that works, but right now, it's not my choice to add it to my system.

 

Roon doesn't support UPnP/DLNA - so why would anyone recommend it for that?

 

However, how about Audirvana or the Logitech Media Server? Both support Qobuz and UPnP/DLNA renderers (LMS requires you also install the Qobuz & UPnP/DLNA bridge plugins; install the Material Skin & Music & Artist Information plugins for a pretty decent Web Control user interface). 🙂

[Cebolla]

14 hours ago, The Computer Audiophile said:

UPnP/DLNA is the most nonstandard standard. Qobuz will be fighting problems with the protocol’s implementation on an hourly basis if it decides to fully support it. I wish this wasn’t the case, but it is. 
 

JRiver, Audirvana, etc... have years of experience applying patches to make things work with different hardware. The Qobuz team has a ton if work ahead it to make this work. 

 

Qobuz themselves appear to be confident that they are more than capable of properly implementing UPnP/DLNA itself and the reason for the delay is due to a security issue with the way the audio is being streamed by their own applications that they need to sort out first:

 

[Cebolla]

13 hours ago, Mike48 said:

So, people are thinking the answer is "no"? Maybe we'll hear from Qobuz themselves.

 

Perhaps what you should be asking is if Qobuz are anywhere near implementing a solution to the 'secure audio flow' issue of their applications, rather than if they intend to get DLNA working.

[Cebolla]

9 hours ago, Mike48 said:

 

Maybe the approach could be to support the devices that do follow the rules.

 

The upmpdcli UPnP renderer front end client for MPD (as used by Sonore devices amongst many others) would be one such - freely available & straight forward to test with.

[Cebolla]

Have you tried using a Qobuz supporting UPnP/DLNA controller app with the CXN instead of the Qobuz app, eg mconnect Player (free Lite version available for testing, special HD version with enhanced landscape display for use on the iPad or Android tablets).

[Cebolla]

I get the Albums display (as well as the Songs, Biography & Similar Artists displays) with no issues after selecting the Artist from the search result in the Qobuz LMS app - tested with the latest LMS (8.0.0 - 1596004420) & Qobuz 3rd party LMS plugin (v2.4.0),  both on an RPi 2B under the DietPi distro and on a Windows 10 laptop; using LMS's built-in Web Interface controller (both Default and Material Skin are ok).

 

Similarly, none of Qobuz's own apps have the problem you mention.

 

Are you also using LMS's Web Interface controller or a different, ie, a third party Squeezebox controller app (if so, which one)?

[Cebolla]

 

[Cebolla]

1 hour ago, brother love said:

Many thanks to all 😃  I installed OpenHomePlayer on the Win 10 mini pc/ renderer. Linn Kazoo & Lumin installed on iPhone X (prefer Linn Kazoo). Success, but Qobuz 24/96 music selections still play as 16/44.1 on DAC (OpenHomePlayer app has no adjustments, just "Open" only).

 

OpenHome Player is openhome.org's test demo player and the Windows version unfortunately only allows use of the default (shared) Windows audio output device. So its audio output is always resampled by the Windows audio mixer to the default Windows audio output device's settings - presumably 16bit/44.1kHz in your Atom's case.

 

The next thing to try is a Qobuz supporting Windows OpenHome renderer that you can set to output to the DAC's audio device in exclusive mode. AFAIK, there aren't any but you can instead use the BubbleUPnP Server helper application (as suggested by @left channel) to 'create' one for a standard UPnP/DLNA renderer that can be set to use audio output devices in exclusive mode, eg:

- either Audiophile UPnP Renderer

- or foobar2000 player with the foo_upnp plugin installed;

- or JRiver Media Center player with its DLNA renderer enabled; etc.

[Cebolla]

  

13 hours ago, brother love said:

Thank @left channel. I had bookmarked that hifizine link this morning, & downloaded the BubbleUPnP Server on the mini PC, but couldn't get it going (got hung up on the media renderer details). Diagram shows it to be installed on music server. May fiddle w/ it so more later.

 

Thanks for the good info @Cebolla ! I downloaded the Audiophile UPnP earlier today, but it was missing a couple .dll files (cause it's 32 bit instead of 64 bit I think).  Will dig deeper into that option tomorrow. 👍

 

 

May be you missed the instruction on the Audiophile UPnP Renderer website that it needs the Microsoft Visual C++ x86 redistributable package for Visual Studio 2015 installed. Also make sure you have the latest AR version (v2.3).

 

BTW, the BubbleUPnP Server requires Java 8 or above installed - it might be best to see if you can get the BubbleUPnP Server working together with the UPnP renderer on the Atom first before moving it to the ideal location on your Linux server (requires a slightly more complex installation).

I'd also suggest the same if you later decide to try out @left channel's other suggestion of using the Logitech Media Server with the Squeezelite player for Qobuz, as LMS is a bit more complicated to install on Linux than on Windows, especially regarding its dependency on Perl.

[Cebolla]

Incidentally, LMS can also be used with standard UPnP/DLNA renderers like AR for Qobuz (requires the UPnP/DLNA Bridge 3rd party LMS plugin as well as the Qobuz one), so should be worth trying that with LMS as an alternative to Squeezelte on the Atom.

[Cebolla]

If you only have access to iOS devices, then mconnect Player (free Lite version available for testing) is an alternative gapless playback supporting standard UPnP/DLNA controller app that also provides access to Qobuz. Make sure you've turned on the Gapless to Renderer option in its Gapless setting.

 

Note: mconnect Player's gapless playback support will only work if the controlled streamer also supports the standard UPnP gapless playback mechanism.

Have you tested if the Songbird streamer actually network streams and plays your own audio files without gaps, never mind those from Qobuz?

[Cebolla]

1 hour ago, Mark Dirac said:

However, I suspect* that it is the tablet which is pulling the stream from Qobuz (and then passing it to the Moode to render), rather than the Moode pulling down the Qobuz directly. Nonetheless, it works very well, and gaplessly, and uses very little battery on the tablet (which leads me to think that perhaps, somehow, it is the Moode which is drawing down the stream from Qobuz, otherwise battery draw on the tablet would be expected to be significant).

 

There's a well documented Qobuz change from over a year ago, including on this thread*, that clearly explains the observation that led you to your suspicion - perhaps, you should have trusted your very little battery drain thoughts more 🙂.

 

 

 

1 hour ago, Mark Dirac said:

*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. Any explanation for this please anyone?

  

*Moode uses upmpdcli as its UPnP renderer, which was reported to have Qobuz API login issues, as just mentioned by @Ran. See posts (and those in between):

 

 

 

1 hour ago, Mark Dirac said:

However I suspect that JKleinbart is wanting an iOS solution, although he doesn't stipulate that.

 

The mconnect Player app 'iOS solution' I mentioned (also available on Android) doesn't appear to proxy Qobuz's streams for its controlled renderer, so the renderer should obtain them directly (via http redirects) from Qobuz.

 

The Android BubbbleUPnP app may or may not proxy, depending on how you have it configured - the default is not to proxy (as long as your renderer isn't in its direct online streaming blacklist):

 

 

[Cebolla]

On 12/5/2020 at 7:56 PM, MikeyFresh said:

I believe that is incorrect, read cebolla's post above. Neither app is set to proxy, they are directing the renderer to go get the stream, but the stream does not flow through the Control Point as you described.

 

Correct, or to be more precise (& hopefully clearer than my last post):

- yes for all UPnP renderers with the mconnect Player app;

- yes in the usual case with the BubbleUPnP Android app, where both Settings>Local and Cloud>Use proxy is not set and the UPnP renderer is not recognised by BubbleUPnP in its internal list of renderers with direct online streaming problems (the majority of HiFi UPnP renderers, including upmpdcli, don't have this problem).

 

 

 

4 hours ago, Mark Dirac said:

Is it the case that Moode can be instructed by BubbleUPnP on Android to go fetch Qobuz data using a key from Bubble? 

 

Yes - BubbleUPnP Android app instructs Moode's upmpdcli to stream, providing it with valid secure URLs for the selected Qobuz audio file track streams.

[Cebolla]

On 12/7/2020 at 1:02 AM, MikeyFresh said:

I find it odd that so many people, even some audio dealers, want to insist that use of those apps in streaming TIDAL or Qobuz involves the stream flowing through the Control Point, and that it ruins the sound quality. So not only is that just incorrect, but if it were accurate, then we'd all be unsatisfied with the sound too, right? But we're not, it sounds great.

 

The notion that a controller app proxying the audio file track streams somehow affects sound quality is totally bogus anyway, as the audio files wouldn't altered in any way:

 

 

Proxying most certainly cannot be compared to AirPlay, say, where the app would actually decode & play the audio file tracks from Qobuz - so it's the app's audio output that's transmitted over the network via AirPlay to the streamer, not the audio files themselves. 

[Cebolla]

On 2/16/2021 at 4:47 PM, The Computer Audiophile said:

Hi Guys, Qobuz through Roon has been extremely slow for me since the Roon version 18 upgrade. I often click on an album in Qobuz but it takes ten second for anything to play. Sometimes longer. When I notice this happening, I switch to the Tidal version of the same album, and it loads instantly. 

 

Anyone else experience this?

 

Blimey, don't tell me you've found a use case for TIDAL's bandwidth saving MQA 😀