Official Qobuz Issues Thread

[Cebolla]

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.

[Cebolla]

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.

[Cebolla]

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"

[Cebolla]

3 hours ago, AMP said:

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.

 

Ah, seeing as you go way back with the BubbleUPnP app you are probably confusing the current situation with the older versions of the app when the gapless support setting was global (and not renderer specific like it is now), so was never greyed out/disabled.

 

Currently, if the renderer's info dialog doesn't mention "Gapless playback potentially supported", then the renderer's individual setting for Enable gapless control is definitely greyed out and therefore disabled. See this post from a few months ago by Michael / @bubbleguuum on the xda-developers forums' BubbleUPnP thread:

https://forum.xda-developers.com/showthread.php?p=76152299#post76152299

Quote

@haggis999

When the 'gapless control' setting was global, it could always be enabled and gapless control was ultimately enabled or not depending on renderer supporting it.
Now, if a renderer does not support the specific UPnP command for gapless, this setting is disabled in the renderer specific settings. Some specific renderers having this command but known to not work are also blacklisted for gapless control, but not Oppo.
You can check if your renderer support this command in the 'top side menu > 3 dot menu on renderer > Info' dialog. If it does, there will be a line 'Gapless playback: potentially supported'.

 

Note especially the mention of "the specific UPnP command for gapless", ie, the SetNextAVTransportURI action!

 

 

 

3 hours ago, AMP said:

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.

 

However, the spec doesn't say that the SetNextAVTransportURI action itself MUST be declared in the XML descriptor's actionlist. The current version of the spec says the SetNextAVTransportURI action is 'A = Allowed', ie, not 'R = Required' (older versions of the spec say it was 'O = Optional').

 

I believe you are declaring the SetNextAVTransportURI action in your XML descriptor, the presence of which the BubbleUPnP app is using to test for gapless support.

 

If that is the case, it seems to me that you are redundantly doing so only because you are 'allowed' to, as there's obviously no functional reason to include it. So its presence when the device doesn't support gapless playback is not really in keeping with the 'logic' of the spec, if not an actual full blown misinterpretation.

 

 

 

3 hours ago, AMP said:

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.

 

Indeed. Perhaps you and @bubbleguuum could sort this issue out in a thread of your own - it would make interesting reading (for me at least)!

 

[Cebolla]

10 hours ago, sockpit said:

Sorry, this is really annoying, David.  The upgraded app drops my mRendu Shairport connection so much it’s not worth it.  Qobuz should revert to previous version or build a report button onto the app so the user can quickly relay the bug and Qobuz quickly fix it.

 

I’m not super computer savvy but it was working with Shairport fine before the last software release.  

 

Interesting that the last release of the Qobuz iOS app appears to have caused an issue with its AirPlay connectivity to the mRendu.

 

Have you tested your iOS device's audio output via AirPlay to the mRendu with another app?

Also, do you have an AirPlay supporting device other than the mRendu to test AirPlay with?

[Cebolla]

10 hours ago, David.. Qobuz, Hi-Res Music Evangelist said:

Not at all and I'm sure it's frustrating for you. I know we all wish UPnP and DLNA were totally standardized (especially me ? . Once they actually get to the Sonore product, I'm sure they'll figure it out. I love their gear and want one myself. I'll pass this on to engineering and find out if there's a planed date to tackle the issues.

 

David,

 

Have you realised that @sockpit's issue is to do an AirPlay connectivity problem with the Qobuz iOS app to play to the Sonore microRendu, ie, it's nothing to do with UPnP/DLNA?

[Cebolla]

1 hour ago, David.. Qobuz, Hi-Res Music Evangelist said:

No. As of now, our guys don't have any of the Sonore product. It's all one step at a time. I'm trying to be a conduit, however can't stress enough that it's still a beta product. At this point, the main goal is to get launched in N/ America, which unfortunately trumps this one feature.

??

 

My question was if you had realised that @sockpit's microRendu issue was about the microRendu being sent audio using the current version of the Qobuz iOS app via the Qobuz app's existing (Apple) AirPlay function (which was apparently working properly in the previous version of the Qobuz iOS app), so it has nothing to do with the getting the Qobuz app to support the (Sonore) microRendu via UPnP/DLNA!

[Cebolla]

Ironic that a post poking fun at those that don't properly read & check previous pages before posting, should use the non-issue of Qobuz "supporting ShairPnNA" as an example of something difficult. ?

 

Most of the relevant posts were even on the same page!

[Cebolla]

On 8/16/2018 at 7:38 AM, nbpf said:

Streaming errors might be difficult to reproduce and hence to fix. But there are errors that are perfectly reproducible and none cares about at Qobuz. All .tar files I have downloaded from Qobuz generate a " tar: A lone zero block at ..." at unpacking. The zero block position "..." is different for different files but constantly the same for the same .tar file. I have reported this error many times and never received any feedback. Not even a notification that they had reproduced the error. I have never seen this problem with .tar downloads from prestoclassical, hyperion, etc. or, indeed, with any other .tar file. 

 

Hi nbpf,

 

I didn't realise that Qobuz currently only provides the option to download your purchased music file tracks contained in the (Linux favoured) tar archive file format. The zip archive format that I'd downloaded before appears to be no longer available from Qobuz, so no point suggesting you use that instead!

 

Using the Linux tar command on my Raspberry Pi (under the latest DietPi distro) to extract or simply list the contents of the Qobuz downloaded tar files definitely produces the "A lone zero block" warning message, though as you say the command otherwise completes as normal. Interestingly, there's no warning message when I use the Windows Z-Zip application (recommended by Qobuz for Windows users) to extract the tar file's contents.

 

Curiosity got the better of me, so I did an online search & had a 'look at the GNU tar file format doc and realised that the block referred to by the tar command warning message was always the final block (tar files use 512 byte blocks). Also, the tar file is supposed to have two zero filled blocks at the end of the file used to indicate its end.

 

I fired up a hex editor to examine the tar files from Qobuz and sure enough they only use one zero filled block for the end of file marker, hence the warning message. A quick but careful copy and paste to add the missing zero block and bye bye Linux tar command warning message. Also, the Windows Z-Zip application still work with the corrected Qobuz tar files.

[Cebolla]

8 hours ago, shadowlight said:

@nbpf, I have a working system with Volumio, MPD, upmpdcli and upmpdcli-qobuz for 16-bit music but with 24-bit music I get white-noise.  I think I am missing some configuration under mpd/upmpdcli, if you know of anything that will help me remove the white-noise let me know what changes needs to be in place for it to make it work.  I can test similar setup as you with Linn Kazoo, mdp/upmpdcli configured as OpenHome renderer.  I only get white noise when I am using Linn Kazoo which uses the upmpdcli-qobuz plugin.  If I use BubbleDS on a Android device which I believe bypasses upmpdcli-qobuz plugin I am able to play 24-bit files just fine.

 

I don't remember any of the old Linn Kazoo / upmpdcli issues having anything to do with getting noise when playing 24-bit files. The upmpdcli manual does warn that some versions of MPD itself have problems playing WAV & AIFF files greater than 16-bit via HTTP, so would include UPnP streaming:

https://www.lesbonscomptes.com/upmpdcli/upmpdcli-manual.html#UPMPDCLI-RENDERER-FORMATS

 

However, not sure how you'd be streaming 24-bit files in an uncompressed PCM file format from Qobuz, as both the BubbleDS Next Android app & upmpdcli-qobuz plugin only provide FLAC files - unless something else is involved in the mix, such as if for some reason you are using a BubbleUPnP Server created OpenHome renderer and have enabled its optional Audio decoding to PCM (ffmpeg) setting. 

 

Certainly avoid using Volumio for upmpdcli/MPD testing, anyway, as those applications come as part of the installation, so you have very little control (if any) of the versions of them that Volumio is using. I'd instead use one of the standard distros for the RPi, such as Raspbian or DietPi, so that you have full control over what versions of MPD & upmpdcli are installed.

 

BTW, you should be able to access Qobuz provided by the upmpdcli-qobuz plugin, instead of Qobuz provided by the Local and Cloud library on the BubbleDS Next Android app, if you select the UPMpd-mediaserver library - it should be selectable just like any other UPnP media server on the network.

[Cebolla]

1 hour ago, shadowlight said:

I update to the latest version of upmpdcli on Volumio before I started testing.  No BubbleUPnP Server involved in the mix.

 

It's been a while since I played with Volumio, but isn't manual/apt-get updates, even of its individual bits and pieces, discouraged?

 

Anyway, try to get the latest build possible for a working MPD, as well - if anything that's more important, for the reason I mentioned earlier. Further info in the Known problems section (just below News) on upmpdcli site main page:

http://www.lesbonscomptes.com/upmpdcli/index.html#news

Quote

The relatively wide usage of upmpdcli and other UPnP mpd front-ends have intensified the testing of the mpd HTTP input plugin quite a lot (because that's how the data is pulled when using UPnP). This has lead to the correction of a number of bugs and bad interactions between the curl input plugin and some decoder plugins. These fix problems (bad sound, clicks, pops, up to pseudo-white-noise) which may depend both on the track format and bitrate. As far as I know most or all these problems are fixed in the current MPD versions (0.19 and later), but, unfortunately, many common Linux distributions lag quite a bit behind current MPD versions. I have set up backport repositories for recent MPD releases for Debian and Ubuntu in hope that they may help with these issues.

 

 

1 hour ago, shadowlight said:

I really should stop posting in the Qobuz thread, since the issue is really outside of Qobuz 

 

You're not the only one - been guilty of going waay off topic already on this thread.

[Cebolla]

6 hours ago, mourip said:

I use JRiver Media Center on my music server to play through the Dante Virtual Soundcard driver out via my ethernet adapter to my Focusrite Rednet ethernet to AES converter. I am extremely happy with the sound quality and so am hesitant to change this configuration. Do you think that it is possible that you might consider partnering with JRiver?

 

Have you approached JRiver to see if they'll consider providing direct access to Qobuz from the JRiver Media Center via a redesign? The Qobuz Application Programming Interface is already available for this purpose:

Qobuz official API documentation

 

For now, you should be able to get able to get your JRiver Media Center to play Qobuz's audio file tracks by using its built-in UPnP/DLNA renderer and so use its playback engine to output the audio to the Dante Virtual Soundcard driver, using one or more of the UPnP supporting applications that provide access to Qobuz.

 

Are you running JMC with the Dante Virtual Soundcard on a Windows or Mac machine?

Are you using a remote control app for JRiver (eg JRemote) on a handheld device with this setup and if so what is the handheld device?

[Cebolla]

The Qobuz desktop app did have (beta) UPnP control point capabilities, but apparently it has been (temporarily?) disabled due to it not behaving very well with the majority of UPnP renderers it has been tried with.

[Cebolla]

On 8/25/2018 at 10:43 PM, left channel said:

The latest update to the Windows app seems to have removed the UPnP/DLNA beta, as David recommended.

 

On 8/26/2018 at 12:10 AM, shadowlight said:

On 8/26/2018 at 12:02 AM, left channel said:

After the update it took a short while for the option to disappear. I can still see my network players in Windows and other apps.

I will keep an eye out for it to disappear.

 

Ah, so it didn't disappear after all - should have checked for myself!

[Cebolla]

2 hours ago, mourip said:

I use Win2012 R2 and control it from my iPhone using JRemote. Works really well. Sometimes I also use RDP to the server.

 

In which case you have the option of trying the MConnect Player Lite app on the iPhone, which as a standard UPnP control point should be able to control JRMC's built-in UPnP/DLNA renderer and also get it to stream from Qobuz. Don't forget to enable JRMC's UPnP/DLNA renderer if you haven't done so already.

 

Another option would be to try the Linn Kazoo app on the iPhone, though being an OpenHome control point you'll also need to run the BubbleUPnP Server on your Win2012 R2 box and configure it to create an OpenHome renderer for JRMC's UPnP renderer.

[Cebolla]

2 hours ago, mourip said:

"Error 500" could have meant anything and even consulting the Universal Source of Truth(Googling) did not help.

 

"HTTP error 500 - Internal Server Error" - it does mean anything could be wrong ☺️

[Cebolla]

4 hours ago, David Craff said:

A+3 sounds better (for you) because it apply some secret audio filter. On Qobuz we do not apply any sound modification.

 

Is it similar in the Qobuz for Mac/PC's UPnP/DLNA renderer output function, ie, is the connected UPnP device streaming the audio (FLAC) file tracks exactly as supplied by the Qobuz online server?

 

Audirvana Plus always transcodes the audio file tracks to WAV files for the UPnP/DLNA streamer, by decoding them first through its audio engine, which also allows any optional filter/DSP settings to be applied.

[Cebolla]

May be continue that conversation in a more relevant thread? Appears to be similar tech, though different startup:

 

[Cebolla]

Deleted - duplicate post.

[Cebolla]

On 10/1/2018 at 1:17 PM, mourip said:

I cannot have both Roon Server and Qobuz running at the same time as ASIO runs in "exclusive mode" and so only wants to service one app at a time. If Roon Server is running then Qobuz will give me an error that the output is "already in use". Add to this that Qobuz has no "server mode" with it's own remote app. This means that I must use RDP on my laptop to control it with Roon Server unloaded.

 

On 10/1/2018 at 1:17 PM, mourip said:

So my ask is can anyone think of a work-around other than what I am already doing?

 

You could try JRiver (or another ASIO supporting audio file player with a much smaller footprint, such foobar2000) set up as a UPnP/DLNA renderer, with a third party method of streaming from Qobuz.

 

For example, the BubbleUPnP Server helper software, configured to create an OpenHome renderer for the UPnP renderer, would allow you to stream from Qobuz using a Qobuz supporting OpenHome controller such as the Linn Kazoo iOS app.

 

Or,  much less complicated with no need for OpenHome/the BubbleUPnP Server and so more direct - just use a Qobuz supporting standard UPnP/DLNA controller iOS app, such as mConnect Player (free Lite version available).

[Cebolla]

Not sure if you've understood: you'd use JRiver or foobar2000 in place of the official Qobuz desktop software on the Win2016 machine, so the music will still be played locally via ASIO, including when you've configured them as UPnP renderers. Running them in their UPnP renderer configuration simply allows you to use a third party (ie, not Qobuz's own app) Qobuz accessing UPnP controller app on an iOS device (eg the mConnect Player app I mentioned), to provide a user interface with Qobuz access for the JRiver or the foobar2000 audio file player running on the still headless Win2016 box - so JRiver's and foobar2000's own user interfaces are irrelevant.

 

Therefore it saves you having to control the Qobuz playback via RDP on your laptop, but I think you still have the issue of the exclusive ASIO access. It's a shame that RoonLabs decided not to let the Roon Core Server support industry standard UPnP/DLNA, otherwise you would have the option to output your Roon playback to either the JRiver UPnP renderer or foobar2000 UPnP renderer running on the same machine and then out to your DAC via ASIO, to avoid the exclusivity issue.

 

Having said that Roon does support outputting to Squeezebox devices and there is software that you can run on Windows that allows UPnP renderers to be used as if the were Squeezeboxes. However, it is a bit complicated to set up, so I suspect not something that you'd consider as KISS!

 

BTW, I believe Qobuz's own software does still support UPnP/DLNA, but they are keeping it quiet as it's a beta feature & not currently very reliable. Also it's only available on the Qobuz desktop version.

[Cebolla]

1 hour ago, left channel said:

Originally it listed any music device on my network, including several Squeezeboxen and an ultraRendu with Squeezelite, though all were incompatible with the Qobuz app. Trying to play to them sent metadata but no audio.  Running DLNA/MPD on the ultraRendu didn't work either. And after the app update, I no longer saw them listed.

 

I recently discovered that I can trick the app into seeing them again by loading UPnPBridge on my ultraRendu, after which that device and all the Squeezeboxes show up in the Qobuz list again.

 

I'm not disputing whether you saw the Squeezebox type devices listed, but I doubt it's because the Qobuz desktop app's UPnP/DLNA streaming support feature also supported Squeezebox streaming, as there's been no mention of it anywhere officially nor otherwise. So the Qobuz desktop app's streamer support is as a UPnP/DLNA controller and not as a Squeezebox controller. Also there's very little chance of Squeezeboxen being listed by accident as UPnP/DLNA streamers, perhaps due to some bug in the Qobuz desktop software, since their device discovery mechanisms are so completely different.

 

What's far more likely is that you were running something else at the same time that was getting the Squeezebox type devices to show up as UPnP/DLNA streamers and thus was tricking the Qobuz desktop app. However, that's very unlikely to be be Sonore's UPnPBridge app, as that's supposed to work the other way around, ie, to trick either the Roon Core Server or the Logitech Media Server into thinking that a UPnP/DLNA renderer is a Squeezebox device!

 

No, the likely candidate is that you were running a version of the Logitech Media Server on some device (eg, LMS is available as an app on Sonore devices) connected to the same network and that the LMS had its UPnP/DLNA Media Interface 1.0 plugin (by Andy Grundman) enabled. This plugin allows LMS to get any Squeezebox type device connected to it to also be listed as a UPnP renderer by any UPnP/DLNA controller app  on the same network and therefore allow the Squeezeboxen to be used by the UPnP controller app as if they were true UPnP renderers. 

[Cebolla]

1 hour ago, left channel said:

I'm not saying the app supported Squeezeboxen at any time. I don't know why I even brought this up, as this feature is after all still in beta

 

Ok, fair enough.

 

 

1 hour ago, left channel said:

To summarize my previous post, when the beta first rolled out the app listed my Squeezy devices but of course did not support them. Then after an update the app no longer saw them. Then when I installed UPnPBridge it saw them again, but was smarter about telling me to get lost. When I uninstalled UPnPBridge it no longer saw them. That is all.

 

I can't see how the Qobuz Desktop app could tell the difference between a true UPnP renderer and one created on a Squeezebox's behalf by the UPnP/DLNA Media Interface LMS plugin.

 

Not sure how come, but I think after the update for some reason, on your particular network, the Qobuz Desktop app's UPnP broadcast request for all UPnP renderers to announce themselves is no longer getting through. However, I suspect the same UPnP broadcast request by the UPnPBridge does get through, with the Qobuz Desktop app riding on its coattails by also picking up the 'I am here' responses from the UPnP renderers, so would include the UPnP/DLNA Media Interface created UPnP renderers.

 

Actually, thinking about it, you haven't at any time mentioned any true UPnP renderers being listed by Qobuz Desktop app, only the ones created for the Squeezebox devices.

 

A quick question - on which network device is your LMS running and therefore the UPnP/DLNA Media Interface created UPnP renderers? If the LMS is on the Sonore, then that would explain why the UPnPBridge's UPnP broadcast request for the UPnP renderers to announce themselves is being picked up by the UPnP renderers created for the Squeezeboxen - they are also on the Sonore.

[Cebolla]

16 hours ago, left channel said:

My LMS is on a microJukebox (the tiniest sonicTransporter-type server from Small Green Computer).  I ran UPnPBridge on a Sonore ultraRendu, where I normally only run Squeezelite. There are also a few actual Squeezeboxes here too, and everything is on a wired gigabit network.

 

Thanks to features like the Qobuz plugin for LMS, I've managed to resist being absorbed by the Roon Borg thus far. I was just playing with UPnPBridge to see if it would shout loud enough to wake up my network neighborhood. Which it did.

 

Ok then, UPnP device discovery doesn't appear to be an issue with your network, seeing as the UPnPBridge is running on a different networked machine to LMS with the enabled UPnP/DLNA Media Interface plugin, but what about the computer you're running the Qobuz Desktop app on? Could a firewall be blocking the updated Qobuz Desktop app's UPnP device discovery requests on its computer?

[Cebolla]

No, no need to apologise, Jussi. I meant broadcast in its common/dumbed down sense, rather than as a network group communication.

 

Actually, what I was 'fearing' on getting pulled up on was the notion that a UPnP control point could pick up the UDP unicast responses from the UPnP devices to another UPnP control point's (multicast) UPnP Discovery message! In reality, it could only be the UPnP devices' regular/heartbeat multicast 'I'm still here' UPnP Notification messages that another UPnP control point would be capable of picking up.

 

One explanation for the Qobuz Desktop app seeming to pick up the LMS 'created for Squeezebox' UPnP renderer responses to the UPnPBridge's UPnP Discovery message is that the receipt of a UPnP Discovery message causes the LMS created UPnP renderers to reinitialise their UPnP Notification message process timers. So may be an initial/immediate UPnP Notification message is sent in addition to the response to the UPnP Discovery message.