Mconnect Qobuz

0 views

Skip to first unread message

Octavis Uberstine

unread,

Aug 3, 2024, 5:18:54 PM8/3/24

to spotenbesub

When I use Mconnect on my iPad to send Qobuz (or local files from DLNA server) to my DLNA renderer, is the audio data stream routed through my iPad or connected directly from source server to renderer? I note that, unlike JRemote for example, closing the MConnect app stops the music. Thanks.

Irrelevant (OP mentions Qobuz as well as own files, not TIDAL) and untrue (as far as mconnect Player providing gapless playback with gapless playback supporting UPnP/DLNA renderers is concerned - as I pointed out to you before).

The mconnect Player app does not handle the files when you are using it to control a streamer, so your UPnP/DLNA renderer will be obtaining them directly from the source server, both your own and the online streaming service's. This will be obvious from the URLs of the tracks that the mconnect Player app sends to the UPnP/DLNA renderer to play as far as your own UPnP/DLNA media server is concerned, but not so in the case of online music service's server, such as Qobuz. In that case, the mconnect Player app has to run its own HTTP server in order to comply with providing secured access to online music streaming service, so the URLs sent to the UPnP/DLNA renderer will be of its own HTTP server. However, importantly its HTTP server only (securely) redirects the requesting UPnP/DLNA renderer to the online music streaming service's server - it does not proxy the online music service's files.

The reason for the music stopping playing when you close the app is likely a question of timing and/or expectation. Remember that in standard UPnP/DLNA streaming the controller provides the renderer with the URLs of the tracks one at a time, not the entire playlist of tracks: some time (depends on the specific UPnP/DLNA controller app - it's about 10 seconds for mconnect Player) before the current track has finished playing in the case of the standard UPnP gapless playback mechanism being enabled or just after the current track has finished playing where gapless playback is not enabled. JRemote is native controller for JRiver Media Center and therefore not necessarily operating as a true standard UPnP control point, so could well be providing JMC with the entire playlist of file tracks to play before playback has even started.

Using BubbleUPnP Server as an example is not really relevant given that its developer makes no secret of it proxying the files to emulate an OpenHome renderer's current playlist - so of course shutting down an OpenHome controller app works as expected!

In your mconnect Player HD app with HQPe example streaming from Qobuz, how can you be certain that HQPlayer has actually requested the Qobuz track (& therefore obtained the redirect to the true URL from Qobuz's online server) from mconnect Player HD's HTTP server in time before you shut the app down & killed its HTTP (redirect) server?

Thanks. Do you mean that with Minimserver rather than JRiver as the DLNA server, MConnect will show a folder view of local files? As JRIver also has a folder view (which works fine for me in JRemote) I presumed the lack of this was simply a shortcoming of MConnect.

That's a JRiver issue with it not exposing its file (folder) view through its DLNA servers. The fact that JRemote can see the view shows how closely JRemote is tied to JRiver as a native remote control (as opposed to a true UPnP/DLNA controller) and isn't actually seeing JRiver though its DLNA servers.

The Logitech Media Server, normally used to provide your own and/or online music to Squeezebox type streamers, would make a decent free alternative to Roon (and has a file/folder view). You'll need to enable the UPnP/DLNA Bridge 3rd party LMS plugin to get it control your UPnP renderer as if it were a Squeezebox. I'd also recommend enabling the Material Skin and Music & Artist Information 3rd party LMS plugins as an excellent alternative to the stock UI provided for LMS's web browser controller,

Ah, I forgot that when you shut the app down normally by using its close function it issues a stop playback command to the controlled streamer just before it closes if the streamer is currently playing a track!

I don't know what the equivalent is on iOS, but on Android the easiest thing to do to avoid the app doing that is to shut down the app by using the force stop function in its Android app settings. Powering down the Android device also works or just forget about shutting the app down & simply disconnect it from the network by turning off the device's WiFi.

Oh dear - in which case you also need turn off the iPad/iPhone's WiFi to prevent the app running in the background from communicating with the streamer. Does powering down the iPad/iPhone not prevent the app from closing down normally & therefore stopping the track?

Ok that is as (I) expected - unless you killed the app just before the end of the current track finishes playing so that the next track's true URL is already known by the renderer via the standard UPnP gapless playback support mechanism (in which case the entire next track should also be expected to be played, but no more).

Not sure why you are of that opinion. Standard UPnP streaming only deals with one single track at a time - it is not even aware of the playlist. Are you possibly confusing standard UPnP streaming with OpenHome (aka UPnP with Linn extensions) streaming, where the OpenHome controller does pass the OpenHome renderer the entire playlist?

Ah, understood - an expectation based on how a streamer should ideally operate as opposed to an expectation based on how it is specified to operate. Yes, I agree standard UPnP streaming is far from ideal and the reason why Linn developed OpenHome in order to improve on standard UPnP. If you think about it, the streamer owning the playlist also greatly simplifies how gapless playback support operates as the streamer will be able to do that by itself and not need the messy involvement of controller app with that.

If you think about it, the streamer owning the playlist also greatly simplifies how gapless playback support operates as the streamer will be able to do that by itself and not need the messy involvement of controller app with that.

Indeed, but why should that control point and renderer exchange be problematic if specific streaming service support is properly defined and thus designed into them (as with OpenHome optionally supporting Qobuz & TIDAL)?

The actual Qobuz online server file track stream URLs only get resolved as and when the tracks are required to be played or buffered for gapless, presumably via an appropriate Qobuz API call using the qobuz protocol URLs & required secure authentication info. No interaction of the Qobuz supporting OpenHome controller (eg Linn Kazoo) with the OpenHome renderer is required for that process to work in the OpenHome renderer, as all the necessary authentication info should have already been exchanged in the controller/renderer interaction where the user originally provided the Qobuz account credentials via the OpenHome controller's Qobuz login function.

Because typically the track URIs are valid only for short time. You need to obtain streaming service content URIs from the streaming services just before it is needed. For that, you need to have support for the streaming service APIs.

In order to browse the content in Control Point, you need to have streaming service support and credentials. Whoever has the playlist, needs to have support for the streaming service and credentials too, because in order to use the playlist, you need to keep communicating with the streaming service when playing through the playlist.

That is ugly as hell. Surprised Qobuz even allows that in first place. And it means both Control Point and Renderer need to have Qobuz support and credentials and know how to talk to Qobuz backend. It means you need to bake in specific Qobuz support into your OpenHome protocol. Makes it very messy to support new streaming services when all involved OpenHome parties need to support it and have credentials for it.

Because typically the track URIs are valid only for short time. You need to obtain streaming service content URIs from the streaming services just before it is needed. For that, you need to have support for the streaming service APIs.

Goes without saying - would be a pointless exercise if that wasn't the case, don't you think? Of course the casual reader of just your quote of my post might not know that was implied, especially as you cut the quote just before the "Certainly the OpenHome playlists' Qobuz tracks would carry on playing on repeat 'forever'" bit.

And it means both Control Point and Renderer need to have Qobuz support and credentials and know how to talk to Qobuz backend. It means you need to bake in specific Qobuz support into your OpenHome protocol.