Official Qobuz Issues Thread

I love localization problems like this. How the Spanish word for "monthly" got in here is probably an amusing story:
 

I'll give them a pass on the double plural ("metadatas"). ?

Thanks for the heads up, LC... Everything's getting translated. I've found quite a few too. We're getting them one by one. Is the the iOS or Android?

Thanks again,

David

Subscribed, and very interested!  +1 for ROON integration as well!

54 minutes ago, David.. Qobuz, Hi-Res Music Evangelist said:

Thanks for the heads up, LC... Everything's getting translated. I've found quite a few too. We're getting them one by one. Is the the iOS or Android?

Thanks again,

David

Android. Thanks David! 

The Qobuz plug-in for LMS (Logitech Media Server) is working really well! I get full Hi-Res streaming to the limits of all devices on my network, features like discovery and PDF booklets are well integrated, and it includes solid French to English and German localization. 

Just go to the Plug-ins tab in Settings and click the Qobuz box, then click Apply and restart. After restart go to Settings > Advanced tab > Qobuz (in the menu) and enter your login info. 

I enjoy exploring with the official Qobuz app and look forward to completion of the UPnP feature, but I'm very happy with this plug-in for LMS. Apparently Qobuz provides good documentation for Michael, Pierre, and other third-party devs.

On 7/26/2018 at 3:46 PM, The Computer Audiophile said:

Definitely some issues with playback here. The second track on the album was skipped. Plus, no metadata appears on the Rossini display  or the dCS app.

If you are using MPD for playback, expect track skip issues on long tracks and when connecting to certain Qobuz servers, please see

https://opensourceprojects.eu/p/upmpdcli/tickets/11/

and

https://github.com/MusicPlayerDaemon/MPD/commit/1ca1269a59e36fc4c91fa9aca93ac6067d9274bf

So far Qobuz has not reacted to any of my issue reports. Thus, I am going to cancel my Qobuz Sublime subscription for the upcoming season. 

25 minutes ago, David.. Qobuz, Hi-Res Music Evangelist said:

LC... I have one in a closet somewhere. So glad you tried this out and thanks for the report. Still upset about Logitech would have just left Slim Devices alone... Why buy a great company and kill it?

 

They bought Slim about nine months before the first iPhone. Then everything changed. Logitech is a mass-market company, and that wasn't going to happen anymore. But it is very much appreciated that they have maintained LMS and the online service, and continue to dedicate one full-time engineer, even as much of the user base has swapped Squeezeboxes for ultraRendus, hi-fi Raspberry Pi projects, and other non-Logitech gear that still relies on their software and services.

I have a mix here: 

•  LMS: SGC microJukebox

•  Players: Squeezebox Duet, Squeezebox Touch (two), ultraRendu, Mac SqueezePlay, Win Squeezelite-X

•  Control apps: Android Squeezer, Win Squeezelite-X

2 minutes ago, nbpf said:

If you are using MPD for playback, expect track skip issues on long tracks and when connecting to certain Qobuz servers, please see

 

https://opensourceprojects.eu/p/upmpdcli/tickets/11/

 

and

 

https://github.com/MusicPlayerDaemon/MPD/commit/1ca1269a59e36fc4c91fa9aca93ac6067d9274bf

 

So far Qobuz has not reacted to any of my issue reports. Thus, I am going to cancel my Qobuz Sublime subscription for the upcoming season. 

No MPD use in this setup right now. 

2 minutes ago, The Computer Audiophile said:

No MPD use in this setup right now. 

If you are using BubbleUPnP Server or a software that attempts at throttling the stream during playback, you might be experiencing the same issue. Apparently the Qobuz app downloads tracks to large buffers instead of throttling the stream, see  

https://github.com/MusicPlayerDaemon/MPD/commit/1ca1269a59e36fc4c91fa9aca93ac6067d9274bf. I have never experienced any issues with the Qobuz app in my network.

3 minutes ago, nbpf said:

If you are using BubbleUPnP Server or a software that attempts at throttling the stream during playback, you might be experiencing the same issue. Apparently the Qobuz app downloads tracks to large buffers instead of throttling the stream, see  

https://github.com/MusicPlayerDaemon/MPD/commit/1ca1269a59e36fc4c91fa9aca93ac6067d9274bf. I have never experienced any issues with the Qobuz app in my network.

My DLNA testing was with the Qobuz desktop app for macOS and a dCS Rossini DAC.

5 minutes ago, The Computer Audiophile said:

My DLNA testing was with the Qobuz desktop app for macOS and a dCS Rossini DAC.

In this case your person in charge is the Qobuz technical support. Good luck, its miserable!

26 minutes ago, The Computer Audiophile said:

My DLNA testing was with the Qobuz desktop app for macOS and a dCS Rossini DAC.

I totally get it... If there's a button, it will be tried. If the button says beta, it will still be tried and people will see first hand why it's listed as beta...

At this point, I've asked the engineers to remove it until it's ready for prime time.

My recommendation: Don't use the UPnP/DLNA and expect it to work well.

Hi all,

I have been doing some testing with dCS Rossini and various DLNA control points using Qobuz and NAS/Minimserver as music sources. I have attached an excel with the summary results.

Qobuz Windows Desktop App DLNA

The Beta DLNA implementation of the Windows Qobuz app does not work well with Rossini at all. Only basic playback seems to work. When one track ends and the next one starts the app usually switched from DLNA to WASAPI and playback via Ethernet stops. This is a no go and it looks like quite some work will be needed to get to a smooth cooperation.

Gapless playback does not work. There is around 1 sec of silence between tracks.

I have informed both dCS and Qobuz of the issues and I am awaiting their feedback.

Qobuz Desktop App via USB/WASAPI works well (as it should via USB), but alas the sound quality is mediocre.

mConnect 

mConnect functions better, but still some serious shortcomings. It does not display the currently played title on the Rossini display and it has (like all the others) the gapless issue. There is always that 1 second gap of silence between tracks.

BubbleUPnP

I liked BubbleUPnP best. It displays the currently played title on the Rossini and the Rossini’s volume control works both from within the app and via the hardware buttons on my Samsung tablet. It does not play gapless though, neither from NAS / MinimServer, nor from Qobuz.

Raspberry Pi / PiCorePlayer

Using a Raspberry Pi with PiCorePlayer as the renderer (plugged into SPDIF1) solves the gapless issue for Qobuz and NAS source, but sound quality is mediocre.

I really hope these issues get sorted out. The most annoying one for me is the lack of gapless playback - a total no go in the context of live albums or opera, where there are no breaks between tracks. DLNA does have a way to manage gapless (SetNextAVTransport function) as outlined in the attached PDF. So in principle the problem should be easy to fix.

DLNA Control Point Compatibility.xlsx

UPnP-av-AVTransport-v1-Service.pdf

Hi jacobacci,

It's probably best to point out that gapless playback support under standard UPnP/DLNA which, as you've mentioned, involves the use of the SetNextAVTransportUri UPnP AVTransport action, is only provided by the interaction between the standard UPnP control point and standard UPnP renderer. In other words, the UPnP media server has absolutely no involvement in the gapless playback mechansim using the SetNextAVTransportUri action.

Therefore any testing of the issues that you are having with standard UPnP/DLNA gapless playback support need only be made with respect to the various standard UPnP control points  & standard UPnP renderers that you are using, not the UPnP media server (ie, no point mentioning using a specific UPnP media server such as MinimServer).

The mConnect Player app is available on both Android and iOS - you didn't say which you are using. This is important, as far as testing for gapless playback support is concerned, since currently only the iOS version of the mConnect Player's standard UPnP control point supports the SetNextAVTransportUri action.

Incidentally, the BubbleUPnP Android app's standard UPnP control point is renowned for its gapless playback support, so much so that it is often used as the goto UPnP controller app for testing the gapless playback of UPnP renderers. If the dCS Rossini is not playing gaplessly when controlled by the BubbleUPnP Android app, you can be assured that it is due to some problem with the Rossini standard UPnP renderer's implementation (or lack of) the SetNextAVTransportUri action.

Also, piCorePlayer uses Squeezelite (a Squeezebox type streamer) as its network audio file player, so is not a UPnP/DLNA renderer. Squeezebox players are incompatible with UPnP/DLNA and use their own mechanism for gapless playback support - therefore have nothing to do with the SetNextAVTransportUri UPnP AVTransport action.

Hi Cebolla

You obviously know much more about streaming than me and I am truly grateful for your clarifications. I am aware that the DLNA server per se has nothing to do with gapless. So I agree that some of my tests were a double dip.

Thanks also for your clarification re. PiCorePlayer. I tested that one with SqueezeCtrl so I stayed within the Squeezebox Ecosystem.

I also have Odroid C2 / Volumio on my Excel. Volumio controlled by Bubble does gapless really well. Would you classify Volumio as a DLNA renderer?

I tested mConnect on Android and iOS, as shown in the excel.

The four problem areas I identified are:

1. Gapless playback not working (with all control points)
2. Metadata not displayed (Qobuz Desktop DLNA, mConnect). This works with BubbleUPnP
3. Seek and skip commands do not work (Qobuz Desktop DLNA)
4. Hardware volume control (on Samsung tablet) does not work (Qobuz Desktop DLNA)

Issue 1 seems to be a dCS Rossini issue.

Issue 2 may be a Qobuz Desktop and mConnect issue

Issue 3 and 4 seem to be Qobuz Desktop issues

I have been trying to get dCS to look into the gapless issue, but I have not had much success so far. Probably I have not been precise enough in my inputs.

In order to get dCS to do something about the gapless issue, do you have a specific suggestion what they would need to test for. I assume it has to do with the way the Rossini handles the SetNextAVTransportUri action (or rather does not).

2 hours ago, jacobacci said:

I tested mConnect on Android and iOS, as shown in the excel.

Yes, sorry didn't have (quick/easy) access to an excel spreadsheet file format viewer at the time of my last post. I have seen the spreadsheet now, though.

2 hours ago, jacobacci said:

I have been trying to get dCS to look into the gapless issue, but I have not had much success so far. Probably I have not been precise enough in my inputs.

In order to get dCS to do something about the gapless issue, do you have a specific suggestion what they would need to test for. I assume it has to do with the way the Rossini handles the SetNextAVTransportUri action (or rather does not).

It should be enough to mention to dCS that the Rossini doesn't play gaplessly when used with known gapless supporting standard UPnP control points such as the BubbleUPnP Android app. Going by your spreadsheet, the Rossini's standard UPnP renderer does declare that it supports the SetNextAVTransportUri action, as otherwise you would not have been able to select the BubbleUPnP app's Enable gapless control option for the Rossini.  If you have a Windows machine you can double check the Rossini UPnP renderer's capabilities by running Whitebear's excellent Media Renderer Analyser:

http://www.whitebear.ch/dmra

Is the Rossini gapless when used with its own dCS Rossini iOS app, BTW?

Both the Rossini DAC & Rossini Player device user manuals say that it is a "control point application" which can allow you to "view / select available renderers" in the "STEP 2 - UPnP Connection" section. So the implication is that the dCS Rossini app contains a UPnP control point for use with the Rossini's UPnP renderer. Unfortunately, I don't have an iOS device to hand to test if the dCS Rossini app can be used with non dCS standard UPnP renderers, so see if does contain a true standard UPnP control point and therefore if it also (properly) supports UPnP gapless.

7 hours ago, jacobacci said:

Raspberry Pi / PiCorePlayer

Using a Raspberry Pi with PiCorePlayer as the renderer (plugged into SPDIF1) solves the gapless issue for Qobuz and NAS source, but sound quality is mediocre.

5 hours ago, Cebolla said:

Also, piCorePlayer uses Squeezelite (a Squeezebox type streamer) as its network audio file player, so is not a UPnP/DLNA renderer. Squeezebox players are incompatible with UPnP/DLNA and use their own mechanism for gapless playback support - therefore have nothing to do with the SetNextAVTransportUri UPnP AVTransport action.

4 hours ago, jacobacci said:

Thanks also for your clarification re. PiCorePlayer. I tested that one with SqueezeCtrl so I stayed within the Squeezebox Ecosystem.

I am getting excellent sound quality from Qobuz via the Squeezbox ecosystem, with best results out of an ultraRendu connected to a DAC via USB. I suspect a hardware upgrade may help, and am wondering if you've tried adding an Allo DigiOne S/PDIF board to your RasPi or swapping in other endpoints. An Allo Usbridge for example.

I'm getting a bit off-topic though, sorry. The piCorePlayer distro and all things squeezy have their own forum over on the forums.slimdevices.com site. The main takeaway here should be is that Qobuz works well in Squeezeworld, and as I reported above does not even require the Qobuz app.

Back on topic, @jacobacci your tests are fascinating and very much appreciated. The Qobuz app's local network streaming beta is still very much a beta, and I understand why David prefers that it be removed for now.

On 8/9/2018 at 2:40 PM, David.. Qobuz, Hi-Res Music Evangelist said:

 

I totally get it... If there's a button, it will be tried. If the button says beta, it will still be tried and people will see first hand why it's listed as beta...

 

At this point, I've asked the engineers to remove it until it's ready for prime time.

 

My recommendation: Don't use the UPnP/DLNA and expect it to work well.

5 hours ago, jacobacci said:

Gapless playback not working (with all control points)

3 hours ago, Cebolla said:

Going by your spreadsheet, the Rossini's standard UPnP renderer does declare that it supports the SetNextAVTransportUri action

None of our products advertise support for NextAVTransportURI. The state variable is specifically set as NOT_IMPLEMENTED. As such gapless playback for any third-party UPnP control point will not work. BubbleUPnP allows you to enable gapless support as a number of renderers don't advertise their renderers correctly and do, in fact, support it.

5 hours ago, jacobacci said:

Metadata not displayed (Qobuz Desktop DLNA, mConnect). This works with BubbleUPnP

5 hours ago, jacobacci said:

Issue 2 may be a Qobuz Desktop and mConnect issue

This is a known issue and we've had an internal ticket open on it for some time. The problem here is that we're expecting the server (in this case the Qobuz desktop app or the mConnect app) to deliver the track metadata embedded in the stream, but neither of these applications do that. This is more of a Qobuz issue as they're the only service that doesn't embed this information in their streams. We receive the metadata in a side channel, but the piece of code that formats the text and pushes it to the display is looking for its data in the stream. We can fix this on our side, but there are more pressing issues at the moment. It's in the queue to be resolved, but I can't predict a release date at the moment.

3 hours ago, Cebolla said:

Is the Rossini gapless when used with its own dCS Rossini iOS app, BTW?

Both the Rossini DAC & Rossini Player device user manuals say that it is a "control point application" which can allow you to "view / select available renderers" in the "STEP 2 - UPnP Connection" section. So the implication is that the dCS Rossini app contains a UPnP control point for use with the Rossini's UPnP renderer.

Our app is not a UPnP control point and doesn't talk to our products using UPnP, rather it uses a protocol that's specific to our network stack. Gapless is supported in native playback engine and that's independent of anything having to do with a standard UPnP implementation. We use UPnP to talk to media servers, but the rest of the implementation is proprietary as some limitations in UPnP made required features impossible without a lot of ugly hacks.

5 hours ago, jacobacci said:

I have been trying to get dCS to look into the gapless issue, but I have not had much success so far. Probably I have not been precise enough in my inputs.

As mentioned before this isn't an issue specific to Qobuz, rather it impacts any UPnP-based control point that talks to our products. Generic UPnP support was added in order to make the products compatible, but for a number of reasons gapless support wasn't included. This has been a long-known issue at dCS, but as the vast majority of our customers use our app or Roon we've focused our efforts on making those two interfaces as stable and feature-rich as possible.

I've been pressing for this feature since long before I started working at dCS and now that I am here I'm in a position to do something about it. At this point it's unknown as to how much effort will be involved in addressing this issue as NextAVTransportURI has never been implemented on this platform. We'll be looking at feasibility in the fall after some other projects are finished and if it's a straightforward task then we'll implement it then. If it ends up being more complex or interferes with a downstream development project then we'll address it when its most appropriate.

Until we have a chance to look at the issue in detail I can't make any predictions, but rest assured that I want to see this resolved so we're going to make our best effort to make it happen.

2 hours ago, AMP said:

5 hours ago, Cebolla said:

Going by your spreadsheet, the Rossini's standard UPnP renderer does declare that it supports the SetNextAVTransportUri action

None of our products advertise support for NextAVTransportURI. The state variable is specifically set as NOT_IMPLEMENTED. As such gapless playback for any third-party UPnP control point will not work.

For gapless playback implementation, I believe the BubbleUPnP app looks for declation of support for the (optional) SetNextAVTransportURI action. I have yet to see the BubbleUPnP Android app allow the Enable gapless control option to be selected for standard UPnP renderers that don't declare support for the SetNextAVTransportURI action - it is greyed out.

If your products can't implement gapless when used with a standard UPnP control point, then perhaps you need to be certain that they are not declaring support for the SetNextAVTransportURI action.

2 hours ago, AMP said:

BubbleUPnP allows you to enable gapless support as a number of renderers don't advertise their renderers correctly and do, in fact, support it.

No, I think you've actually got this all inverted. BubbleUPnP only enables gapless support for those renderers that declare they support gapless (ie, the SetNextAVTransportURI action) and allows the user the option to disable it for those renderers that declare gapless support, but don't implement it properly. Here's the actual help/warning text that appears next to BubbleUPnP's Enable gapless control tick box :

"Gapless works only with renderers supporting it properly. If enabled, can mess up track advance with some buggy renderers"

1 hour ago, Cebolla said:

For gapless playback implementation, I believe the BubbleUPnP app looks for declation of support for the (optional) SetNextAVTransportURI action. I have yet to see the BubbleUPnP Android app allow the Enable gapless control option to be selected for standard UPnP renderers that don't declare support for the SetNextAVTransportURI action - it is greyed out.

Hasn't been my experience. In all the years I've used BubbleUPnP it has allowed this box to be checked on renderers that don't advertise gapless support. I have a couple of other renderers here that don't support gapless and yet BubbleUPnP still allows the setting. One of them shows "gapless: potentially supported" (which is the same as what our devices show as well) and the other makes no mention of gapless in the renderer info. I've never seen the option greyed out in over 5 years of using the software.

Michael is a smart guy and he knows that a lot of UPnP devices on the market don't properly advertise gapless support so it would appear that if they show certain traits of _possibly_ supporting gapless the user is informed of such.

1 hour ago, Cebolla said:

No, I think you've actually got this all inverted. BubbleUPnP only enables gapless support for those renderers that declare they support gapless (ie, the SetNextAVTransportURI action) and allows the user the option to disable it for those renderers that declare gapless support, but don't implement it properly.

I honestly don't know what BubbleUPnP is looking at but the UPnP spec is pretty clear on how a device is supposed to inform control points of support for gapless playback:

Quote

 

2.2.21 NextAVTransportURI

This state variable contains the AVTransportURI value to be played when the playback of the current AVTransportURI finishes. Setting this variable ahead of time (via action SetNextAVTransportURI()) enables a device to provide seamless transitions between resources for certain data transfer protocols that need buffering (for example, HTTP). If the service implementation does not support this feature, then this state variable MUST be set to “NOT_IMPLEMENTED”.

 

NextAVTransportURI is the variable that contains the URI of the next track to be played. SetNextAVTransportURI is the UPnP command action used to SET the value of this variable. Per the spec this variable MUST be defined in the device's AVTransport XML descriptor regardless of whether or not the device supports the feature. If the device doesn't support the feature then the variable must be set to a default value of "NOT_IMPLEMENTED"

Here's the relevant excerpt from our XML descriptor:

<stateVariable sendEvents="no">
<name>NextAVTransportURI</name>
<dataType>string</dataType>
<defaultValue>NOT_IMPLEMENTED</defaultValue>
</stateVariable>
<stateVariable sendEvents="no">
<name>NextAVTransportURIMetaData</name>
<dataType>string</dataType>
<defaultValue>NOT_IMPLEMENTED</defaultValue>
</stateVariable>

BubbleUPnP allows me to enable gapless support on this device, but it doesn't work because the device doesn't support it (as evidenced by XML above).

I'm not sure what BubbleUPnP is looking at to see if gapless is "potentially supported" but it's not basing that decision on what the actual spec tells device developers to do. Of course, most UPnP devices don't bother to follow the spec, hence the reason compatibility problems are rampant.

Anyways, this is WAAAY off the original topic, but I wanted to be sure that the correct information was provided so as not to cause any further confusion.

40 minutes ago, AMP said:

I wanted to be sure that the correct information was provided so as not to cause any further confusion.

Thanks Andrew.