02-25-2024, 02:02 PM
Both mconnect and BubbleUPnP act as proxy to the upstream Qobuz service. It seems the BubbleUPnP coders chose to include that fact in the track URLs they construct while the mconnect coders did not. Interesting. Either way, the URL is correct for its specific app.
So the IP contained in the OP's offending URL is the IP occupied by the Android phone/ BubbleUPnP combo when it was feeding that Qobuz track to the moOde player.
I don't use UPnP except in brief tests and I haven't paid attention to whether the moOde playback queue retains track info from previous UPnP Control Points when a new one takes over. Nor do I know if this behavior is different when the UPnP Renderer is set to service type "UPnP-A/V" versus "OpenHome" (to match the capability of the Control Point). I routinely clear the queue during testing anyway so I may have dodged a bullet without knowing it.
Good catch, @bsergiu
Regards,
Kent
So the IP contained in the OP's offending URL is the IP occupied by the Android phone/ BubbleUPnP combo when it was feeding that Qobuz track to the moOde player.
I don't use UPnP except in brief tests and I haven't paid attention to whether the moOde playback queue retains track info from previous UPnP Control Points when a new one takes over. Nor do I know if this behavior is different when the UPnP Renderer is set to service type "UPnP-A/V" versus "OpenHome" (to match the capability of the Control Point). I routinely clear the queue during testing anyway so I may have dodged a bullet without knowing it.
Good catch, @bsergiu
Regards,
Kent
