Official Qobuz Issues Thread

[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.

 

[deho]

35 minutes ago, Cebolla said:

 

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.

I also suspect something like that ...

Thank you for your explanation.

[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.

[The Computer Audiophile]

35 minutes ago, Cebolla said:

 

 

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.

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. 

[MikeyFresh]

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.

[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.

[deho]

Reading all your interesting comments, I now think that the problem comes from the Qobuz streamed files size, encoding or http distribution. If I stream directly from my NAS (without using Bubble UPNP server) a previously purchased and downloaded Hi-Res Qobuz file to the Technics, even the heaviest ones (24/196), it works seamlessly ... Why not when the same file comes from the Qobuz server ? Or is it a flaw of the Technics ?

[David Craff]

15 hours ago, deho said:

For information, during the short period of time where Qobuz desktop app. was able to stream to DLNA/UpNp players, it was working well ... I hope they will revert that service quickly !

 

Hi,

 

This feature is still available in its beta version. You just need to activate it in the application settings. It can be found in the "Music Playing" tab. 

 

Regards

[David Craff]

13 hours ago, RichardSF said:

@David Craff,

There is something fundamentally wrong with this album on Qobuz. The album as released by Sony Classical should contain Bruch and Mozart, but Qobuz is playing the wrong tracks.

 

Here is the same album on different services:

Qobuz: http://open.qobuz.com/album/0886443008885

Spotify: https://open.spotify.com/album/0HVxeWHCCZhndxGCmUYXIA

Tidal: https://tidal.com/browse/album/7794551

Google: https://play.google.com/music/preview/Bmop6ovazz3pbkpfdtnzpqm5ioi

 

The album should play the tracks as listed (Bruch followed by Mozart). It plays correctly on the other services but on Qobuz the album plays Mendelssohn followed by Bruch. 

 

 

 

Thanks for this feedback, I send this to the support. Feel free to do that with the link if you find other problem.

 

Regards

[deho]

9 minutes ago, David Craff said:

 

Hi,

 

This feature is still available in its beta version. You just need to activate it in the application settings. It can be found in the "Music Playing" tab. 

 

Regards

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. The problem then only occurs when it is managed by mConnect ... It's weird !!!

[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?

[deho]

23 minutes ago, Cebolla said:

 

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.

 

Perhaps @David Craff can clarify this?

You are right ! Maybe the Qobuz app. is behaving somewhere like Audirvana and caching the music before sending it to the player ... No idea about that hypothesis but that also makes sense. I will try to find amongst the files and folders of my Mac if there is something like a Qobuz cache.  

[deho]

If it is verified, I then have to change my mind on the problem : the flaw would then be with the Technics SU-R1 network player ! Pitiful for such an high end device called "Reference" ... Hope some Technics people are reading !

[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.

[deho]

The idea of a cache seems to be confirmed. I've found a 4 Gig Qobuz folder in the ~/UserApplication/Library/Application Support/Qobuz with several cache folders ...

[David Craff]

1 hour ago, Cebolla said:

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.

 

Our first implementation of UPnP was to directly send the url of the track to the UPnP Player. As I said before, this is a problem for most of UPnP player. So the next step, is to transform the desktop application into UPnP Server. This one will take the audio from ours media servers and distribute to UPnP player via is own UPnP server.

 

In this way, by using the same protocol between emitter and receiver, a good compatibility is ensured.

[David Craff]

1 hour ago, deho said:

The idea of a cache seems to be confirmed. I've found a 4 Gig Qobuz folder in the ~/UserApplication/Library/Application Support/Qobuz with several cache folders ...

 

This cache can only be used by the Qobuz Application

[deho]

So, if I have well understood all of these interesting posts, the culprit of my problems is definitively the Technics SU-R1 network player, which apparently, alike several of its congener, is unable to read directly url's of Hi-Res  tracks from Qobuz (despite it works seamlessly with Std-Res tracks). The Qobuz app. is working like Audirvana or Bubble UpNp or other UpNp servers and is caching the flow of music to allow better compatibility with these Hi-Res tracks ... Then mConnect will not work since it is addressing the tracks' url's directly to the player ! 

 

I feel less stupid about UpNp and streaming today : thank you all for your explanations.

[David Craff]

21 minutes ago, deho said:

The Qobuz app. is working like Audirvana or Bubble UpNp or other UpNp servers and is caching the flow of music to allow better compatibility with these Hi-Res tracks

 

No the Qobuz app did not do that yet, but must do in the futur.

[deho]

3 minutes ago, David Craff said:

 

No the Qobuz app did not do that yet, but must do in the futur.

So what is the use of all these cache folders I've found in the Qobuz folder ?

[deho]

BTW, does anybody know if Bubble UpNp control app. is due to become compatible with iOs devices ?

[David Craff]

1 minute ago, deho said:

So what is the use of all these cache folders I've found in the Qobuz folder ?

 

This is used by the Qobuz application when you play music with direct connexion audio device, like an usb DAC. This help to have faster answer to play music.

When you choose to use network audio device, like Google Cast or DLNA. The cache is not use. The netword audio device call our media servers.

There is only communication between the Qobuz Desktop application and the network audio output in order to be informed of changes.
The Qobuz application then acts as a remote control for the network audio output.

[The Computer Audiophile]

36 minutes ago, deho said:

feel less stupid about UpNp and streaming today : thank you all for your explanations.

Here is something I wrote 7 years ago. 
 

 

 

[Gus141]

5 hours ago, David Craff said:

 

Our first implementation of UPnP was to directly send the url of the track to the UPnP Player. As I said before, this is a problem for most of UPnP player. So the next step, is to transform the desktop application into UPnP Server. This one will take the audio from ours media servers and distribute to UPnP player via is own UPnP server.

 

In this way, by using the same protocol between emitter and receiver, a good compatibility is ensured.

My experience with DLNA/UPnP if interested:

 

—turning on the DLNA/UPnP beta in the Qobuz app (MacOS) does not work in my setup: the app sees my Oppo 205 and a Lumin U1 Mini (they are listed in the audio device list) and I can select each one (getting the check mark), but after selecting a song to play, the song never plays

 

—mConnect app sees my Oppo 205 and Lumin U1 Mini and performs DLNA/UPnP controller duties without issues as long as I keep the iOS app in the foreground and don’t do any app switching/multi-tasking (this is when streaming Qobuz and TIDAL); no dropouts, no glitches (tested up to 24/192 on Qobuz)

 

I really wish whatever mConnect is doing correctly could be implemented in the Qobuz iOS app directly 😉. As a minimum, hopefully the API team keeps adding functionality for third-party UPnP controllers like mConnect so that the experience is just as fun as using the native app.