Official Qobuz Issues Thread

[Cebolla]

6 hours ago, rickca said:

David, Qobuz integration in A+ works great with UPnP/DLNA renderers.  How did Damien solve this?

 

I'd guess by trial and error with much of the data obtained by its many 'willing' guinea pigs, given that every paid A+ user has a vested interest and is therefore a potential beta tester!

 

 

Looks like the Windows version of A+ still needs some feedback help from its users:

6 hours ago, shadowlight said:

Believe me I would love to use A+ but as of right now I have had stability issues with it on Win10 enterprise system with dump files being created when it crashes.  I am hoping Damien sees my message on the A+ thread.

 

[David Craff]

13 hours ago, loop7 said:

I'm exploring the desktop Qobuz app both connected directly to a DAC and via Chromecast (the HDMI version).

 

It seems the Qobuz app doesn't recognize the first generation Chromecast but does recognize the gen 2 Chromecast. 

 

I'm assuming there are limitations of the first version that make it problematic.

 

Just an observation.

 

Hi,

 

Can you explain the issue you have with  the first generation Chromecast ?

 

Recently Google made some changes to the Chromecast SDK which generated listening issues between our applications and Chromecast, when everything was working well.  We are in contact with Google to find a solution.

 

Moreover, a redesign of the Qobuz interface for Chromecast will be available in the coming weeks.

 

Regards

[David Craff]

12 hours ago, shadowlight said:

For me the support for Roon and UPnP/DLNA are two parallel track.  One is development by Roon, while the other is development by Qobuz.  For me Roon brings the benefit of having my streaming and local music managed by single interface, for now I am perfectly happy to use BubbleUPnP client on Android phone/tablet or mConnect on IOS devices with Minimserver.  

 

I rather have access to Qobuz and let Qobuz release a stable client when they are ready.

 

We have on our backlog the feature to play local music even they don't come from Qobuz.

[David Craff]

8 hours ago, AudioDoctor said:

I don't know who to tag here, so I will tag both @damien78 and @David.. Qobuz, Hi-Res Music Evangelist

 

One of my frustrations using Audirvana+ with Qobuz is this, I will be searching through for an album and find 5 different versions and have to click on each one to find which is which, or if I can play them at all.  If there was a way you guys could figure out a way to make the searching easier within A+ that would be great.

 

edit:  Here are 4 examples

 

 

 

There is a work in Qobuz to correct this issues. But no date yet.

 

Regards

[David Craff]

6 hours ago, rickca said:

David, Qobuz integration in A+ works great with UPnP/DLNA renderers.  How did Damien solve this?

 

I don't know in detail what A+ is doing for the UPnP. What I do know is that we tried to send the url of the audio file directly to the UPnP player. However, the header in the request on our servers is a problem for a large majority of these readers.

 

As A+ or BubbleUPnP do (if I'm not mistaken) the objective will be to get the audio file from Qobuz and then send it to the readers. That's why I'm talking about transforming our application into a url server. At that time we will have control over the headers in the request and will be able to adapt it to the UPnP's needs. It will also be possible at this time to convert the file to another format such as WAV, which is less problematic than Flac for UPnP.

[Martin H]

1 hour ago, David Craff said:

 

I don't know in detail what A+ is doing for the UPnP. What I do know is that we tried to send the url of the audio file directly to the UPnP player. However, the header in the request on our servers is a problem for a large majority of these readers.

 

As A+ or BubbleUPnP do (if I'm not mistaken) the objective will be to get the audio file from Qobuz and then send it to the readers. That's why I'm talking about transforming our application into a url server. At that time we will have control over the headers in the request and will be able to adapt it to the UPnP's needs. It will also be possible at this time to convert the file to another format such as WAV, which is less problematic than Flac for UPnP.

Just to check my understanding. So the solution you are describing, when in place, should preserve the hires quality (e.g. 24/192 or 96) and the customers local DS/DAC handles the decoding, not the pc. Sounds awesome. 

[rickca]

2 hours ago, David Craff said:

As A+ or BubbleUPnP do (if I'm not mistaken) the objective will be to get the audio file from Qobuz and then send it to the readers. That's why I'm talking about transforming our application into a url server. At that time we will have control over the headers in the request and will be able to adapt it to the UPnP's needs. It will also be possible at this time to convert the file to another format such as WAV, which is less problematic than Flac for UPnP.

OK that's exactly how A+ handles this issue.  

[David Craff]

3 hours ago, Martin H said:

Just to check my understanding. So the solution you are describing, when in place, should preserve the hires quality (e.g. 24/192 or 96) and the customers local DS/DAC handles the decoding, not the pc. Sounds awesome. 

 

No. Of course we keep the audio quality but instead of providing at the UPnP output urls of audio files such as "http://www.qobuz.com/fileXXX.flac" we will give urls such as "QobuzDesktop/fileXXX.flac". On these last urls we will be able to do what it takes to make them compatible with UPnP outputs.  The Qobuz Desktop will download  the file from "http://www.qobuz.com/fileXXX.flac" keep in application cache and give another url to de UPnP Output to read this file.

[shadowlight]

1 hour ago, David Craff said:

 

No. Of course we keep the audio quality but instead of providing at the UPnP output urls of audio files such as "http://www.qobuz.com/fileXXX.flac" we will give urls such as "QobuzDesktop/fileXXX.flac". On these last urls we will be able to do what it takes to make them compatible with UPnP outputs.  The Qobuz Desktop will download  the file from "http://www.qobuz.com/fileXXX.flac" keep in application cache and give another url to de UPnP Output to read this file.

Wouldn't doing that introduce the delay for playback?  For example I want to listen to a complete album, am I going to have to wait until the album is completely downloaded before it will start playback?  Even if it starts playing after the first song is downloaded that is still going to introduce the delay.

 

I think Qobuz is trying to re-event the wheel here, considering you have at least three examples of UPnP streams working correctly for Qobuz (BubbleUPnP, mConnect and A+).  Maybe Qobuz could collaborate with the authors of those apps to address the issue in the current code.

[AudioDoctor]

10 hours ago, David Craff said:

 

There is a work in Qobuz to correct this issues. But no date yet.

 

Regards

 

Good to hear, thank you.

[loop7]

18 hours ago, David Craff said:

Hi,

 

Can you explain the issue you have with  the first generation Chromecast ?

 

Recently Google made some changes to the Chromecast SDK which generated listening issues between our applications and Chromecast, when everything was working well.  We are in contact with Google to find a solution.

 

Obviously these are only reproducible on the devices I have so it's anecdotal.  I did factory reset both of the Chromecasts I'm using (Gen 1 and Gen 2)

 

Using the Mac OS Qobuz app (Mac OS 10.1.6):

 

Chromecast Gen 1 has never appeared as an output (see image).

 

 

Using the Android Qobuz app (OS 9):

 

1. Chromecast Gen 1 always appears as an output but without the Chromecast label; Chromecast Gen 2 is always labeled.

 

2. When switching between mp3 and 16/44, the indicator on the display connected to the Chromecast changes but not on the Android app itself; app indicator mp3 icon remains regardless of quality setting.

 

3. Music playing via the Chromecast Gen 1 rarely seems to skip.

Note: Chromecast Gen 2 plays mp3 quality without any problems but drops out constantly during 16/44 playback, regardless of control application. My wifi and overall network is fairly robust.

 

 

[Cebolla]

15 hours ago, shadowlight said:

Wouldn't doing that introduce the delay for playback?  For example I want to listen to a complete album, am I going to have to wait until the album is completely downloaded before it will start playback?  Even if it starts playing after the first song is downloaded that is still going to introduce the delay.

 

The proposed proxying mechanism will inevatibly introduce a (slight) delay, but you certainly won't be waiting for the current file track to be "fully downloaded", let alone the whole playlist/album of tracks, before the music starts playing. We are still talking about a streaming mechanism here, only via an indirect method with introduction of a middle man - so nothing to do with downloading.

 

Not sure where you got the idea of the whole playlist/album being involved, anyway - standard UPnP only ever deals with the current audio file track for playback, plus the 'luxuary' of having to also start streaming next audio file track before the current one has finished playing if gapless is supported.

 

 

15 hours ago, shadowlight said:

I think Qobuz is trying to re-event the wheel here, considering you have at least three examples of UPnP streams working correctly for Qobuz (BubbleUPnP, mConnect and A+).  Maybe Qobuz could collaborate with the authors of those apps to address the issue in the current code.

 

Ironically, it's precisely those applications that are examples of UPnP controllers that do proxy the audio file track streams when they are sourced from online music services.

 

One of Audirvana Plus's 'selling points' is that the audio files are always decoded by its audio engine before being repackaged as WAV files for UPnP streaming - this even includes local audio files, not just those that are sourced from an online service like Qobuz! 

[davidovada]

On 10/14/2018 at 6:08 PM, left channel said:

 

@davidovada were you able to clear this up by contacting Qobuz? 

 

For anyone wondering what this is about, I've posted info on the new EU pricing in the Qobuz USA launch thread:

 

sorry I took so long to respond. I've been in the wilds of south india with no connection. Qobuz responded by telling me that the credit card on file now must match the country where you've subscribed. As I have used a work around address in France for many years, my Italian card will no longer work. They suggested I close my current account. I asked if I would lose all of my close to 800 favorites. They have never responded(which is really not cool). Anyone from Qobuz care to comment?

[David Craff]

19 hours ago, shadowlight said:

Wouldn't doing that introduce the delay for playback?  For example I want to listen to a complete album, am I going to have to wait until the album is completely downloaded before it will start playback?  Even if it starts playing after the first song is downloaded that is still going to introduce the delay.

 

I think Qobuz is trying to re-event the wheel here, considering you have at least three examples of UPnP streams working correctly for Qobuz (BubbleUPnP, mConnect and A+).  Maybe Qobuz could collaborate with the authors of those apps to address the issue in the current code.

 

We do not re-event the wheel and we have already collaborate with BubbleUPnP. 

[David Craff]

8 hours ago, loop7 said:

 

Obviously these are only reproducible on the devices I have so it's anecdotal.  I did factory reset both of the Chromecasts I'm using (Gen 1 and Gen 2)

 

Using the Mac OS Qobuz app (Mac OS 10.1.6):

 

Chromecast Gen 1 has never appeared as an output (see image).

 

 

Using the Android Qobuz app (OS 9):

 

1. Chromecast Gen 1 always appears as an output but without the Chromecast label; Chromecast Gen 2 is always labeled.

 

2. When switching between mp3 and 16/44, the indicator on the display connected to the Chromecast changes but not on the Android app itself; app indicator mp3 icon remains regardless of quality setting.

 

3. Music playing via the Chromecast Gen 1 rarely seems to skip.

Note: Chromecast Gen 2 plays mp3 quality without any problems but drops out constantly during 16/44 playback, regardless of control application. My wifi and overall network is fairly robust.

 

 

 

Thanks for this feeback, I will test and check this.

Regards

[left channel]

1 hour ago, davidovada said:

sorry I took so long to respond. I've been in the wilds of south india with no connection. Qobuz responded by telling me that the credit card on file now must match the country where you've subscribed. As I have used a work around address in France for many years, my Italian card will no longer work. They suggested I close my current account. I asked if I would lose all of my close to 800 favorites. They have never responded(which is really not cool). Anyone from Qobuz care to comment?

 

I have a solution. I will PM you. 

 

[shadowlight]

@Cebolla, @David Craff thanks for the information.  I was afraid that if I select to play the whole album I would have to wait.

 

From some troubleshooting that I have done between BubbleUPnP and HQPlayer Embedded I noticed that BubbleUPnp sends it's own stream location http://10.*.*.*/ which when HQPlayer tries to pull, it basically redirects users to the actual http://stream2.qobuz.com address.  This is all based on the logs on HQPlayer server.

 

I am looking forward to the release.

[steveoat]

Are we any closer to a launch?

 

About a week or so ago, Qobuz, on facebook, mentioned that those who signed up for early notification would hear soon.  Any news as to when this might be?

[rodrigaj]

48 minutes ago, steveoat said:

Are we any closer to a launch?

 

About a week or so ago, Qobuz, on facebook, mentioned that those who signed up for early notification would hear soon.  Any news as to when this might be?

LOL, I've been waiting for notification for years. Never once received an email, even when RMAF was scheduled.

 

Your best bet is to hang out here.

[André Gosselin]

9 hours ago, Cebolla said:

 

Not sure where you got the idea of the whole playlist/album being involved, anyway - standard UPnP only ever deals with the current audio file track for playback, plus the 'luxuary' of having to also start streaming next audio file track before the current one has finished playing if gapless is supported.

 

Ironically, it's precisely those applications that are examples of UPnP controllers that do proxy the audio file track streams when they are sourced from online music services.

 

 

Cebolla, your answer seems to imply that, when streaming to a UPnP renderer from the BubbleUPnP android app, audio files are proxied to the local control point. This is not my experience. I can launch a stream of a whole Qobuz album to my renderer (sonore microrendu) from BubbleUPnP and shut down my tablet. The album tracks will play to the end. I can regain control of the renderer and the playlisr from a BubbleUPnP instance running on a different tablet. This shows that the renderer, being of an OpenHome type, owns the playlist and connects directly to the Qobuz server. No proxying should be involved here, unless, I am totally wrong.

 

Note that I am using a standard Qobuz account, so no streaming in CD or HR quality. Would that make a ifference ?

[shadowlight]

That is my experience with both Bubble and mConnect where the tablet gets out of the way.

[jvvita]

This is also my experience, with Qobuz in CD quality. But my favorite way of listening is selecting the album on the Qobuz android app, and using the "share with bubbleupnp" function to stream to the renderer (PSAudio Bridge II). This way I get all the bells and whistles of the Qobuz app, have the music files cached in my SD card for further listening (the quality is a bit better), and use the upnp protocol to its fullest extent. 

[Cebolla]

On 10/26/2018 at 3:55 PM, shadowlight said:

From some troubleshooting that I have done between BubbleUPnP and HQPlayer Embedded I noticed that BubbleUPnp sends it's own stream location http://10.*.*.*/ which when HQPlayer tries to pull, it basically redirects users to the actual http://stream2.qobuz.com address.  This is all based on the logs on HQPlayer server.

 

Yes, if you are talking about the BubbleUPnP Android app (and without it being used in combination with the BubbleUPnP Server for OpenHome), then it does normally redirect as opposed to proxy. However, the Use proxy option must be unset and the UPnP renderer must not be in the app's blacklist of those that have problems playing online streams.

 

However, the BubbleUPnP Server always proxies its created OpenHome renderers' current playlist file track streams for the online music services that it supports.

 

 

 

17 hours ago, shadowlight said:

That is my experience with both Bubble and mConnect where the tablet gets out of the way.

 

Yes, sorry - mConnect was also in your list of examples and I should not have implied that it also proxies, as it only seems to redirect (well specifically, the mConnect Player Lite Android app redirects - I haven't tried the other mConnect app versions).

 

Presumably, since mConnect Player is a standard UPnP controller and doesn't support OpenHome, the "tablet gets out of the way" with the mConnect (Player) app is just for the current track. Plus, if gapless is supported by the renderer & the MConnect Player's Gapless option is set, the next track too, but only if the SetNextAvTransportURI action has been issued by the controller - I believe tne mConnect Player app sends the SetNextAvTransportURI action close to the end (~10s) of the current track playing.

 

This of course assumes the renderer has already taken the redirection(s) to the Qobuz online server from the mConnect Player's current (& next) track URI(s), before the tablet is "out of the way".

 

[Cebolla]

20 hours ago, André Gosselin said:

Cebolla, your answer seems to imply that, when streaming to a UPnP renderer from the BubbleUPnP android app, audio files are proxied to the local control point. This is not my experience. I can launch a stream of a whole Qobuz album to my renderer (sonore microrendu) from BubbleUPnP and shut down my tablet. The album tracks will play to the end. I can regain control of the renderer and the playlisr from a BubbleUPnP instance running on a different tablet. This shows that the renderer, being of an OpenHome type, owns the playlist and connects directly to the Qobuz server. No proxying should be involved here, unless, I am totally wrong.

 

Yes, the BubbleUPnP Android app won't be proxying when operating as an OpenHome control point for an OpenHome renderer. I'm not sure why you think I may have been implying that, given that in that post I mentioned standard UPnP operation plus that standard UPnP only deals with the playlist's current & next track (if gapless is supported), so clearly not OpenHome.

 

However, I believe your specific OpenHome case does actually involve proxying, but not by BubbleUPnP Android app!

 

Unless the Sonore microRendu's specification has changed since I last checked, it is a standard UPnP renderer, not an OpenHome renderer. You can create an OpenHome renderer for it with the BubbleUPnP Server helper application, which is presumably what you have done.

 

So like I mentioned above, the BubbleUPnP Server always proxies its created OpenHome renderers' current playlist file track streams for online music services - ie, for both Qobuz & TIDAL, which are the only online music services that the BubbleUPnP Server currently supports.

 

 

 

20 hours ago, André Gosselin said:

Note that I am using a standard Qobuz account, so no streaming in CD or HR quality. Would that make a ifference ?

 

It doesn't make any difference; proxying occours with the BubbleUPnP Server's created OpenHome renderers, regardless of the type of Qobuz or TIDAL account used to connect with.

[Martin H]

17 hours ago, jvvita said:

This is also my experience, with Qobuz in CD quality. But my favorite way of listening is selecting the album on the Qobuz android app, and using the "share with bubbleupnp" function to stream to the renderer (PSAudio Bridge II). This way I get all the bells and whistles of the Qobuz app, have the music files cached in my SD card for further listening (the quality is a bit better), and use the upnp protocol to its fullest extent. 

Hi

 

When you say that you 'share' with bubbleupnp' from the Qobuz app  - what exactly do you mean and how do you do that? 

 

Apologies if I am being dumb but I spent some time looking in various apps earlier on my android phone and couldnt find it.