bubbleupnpserver & Denon Heos

[Michael Waldor]

I'm running bubbleupnpserver in its latest version from january 2025 on a raspbery pi 4 to create an openhome renderer of my Denon x6400h AVR. Gapless playback is enabled. I can e.g. select an album from Qobuz. It is played fine, except for the last track. It stopps immedeately. Afterwards sending commands to that openhome renderer from bubbleupnp controller is locked for some time.

bubbleupnp itself had a similar problem on Android, being fixed with one of the last releases of bubbleupnp in 2025. Please check if the same bug within bubbleupnpserver can be fixed in a similar way.

Additionally, with both programs some metadata within Denon's now playing screen on TV are missing, IF the track change is done automatically as the playlist proceeds. But they are shown IF one manually selects a new track within playlist. Missing fields are remaining time, hires icon, and bitrate.

One final question w.r.t. stopping playback from bubbleupnpserver if one switches of the Denon AVR or changes input  (only standby, network connection still active). Will that automatically do pause? If not I'd suggest that bubbleupnpserver should automatically set its current playlist to pause. It might be continued later from bubbleupnp controller by pressing play. There must be no automatic start of playback when Denon renderer is switched on.

Hopefully you can fix/solve my issues...

Regards & thanks, Michael

[Michael Pujos]

Hi,

On Friday, January 2, 2026 at 2:45:47 PM UTC+1 Michael Waldor wrote:

I'm running bubbleupnpserver in its latest version from january 2025 on a raspbery pi 4 to create an openhome renderer of my Denon x6400h AVR. Gapless playback is enabled. I can e.g. select an album from Qobuz. It is played fine, except for the last track. It stopps immedeately. Afterwards sending commands to that openhome renderer from bubbleupnp controller is locked for some time.

bubbleupnp itself had a similar problem on Android, being fixed with one of the last releases of bubbleupnp in 2025. Please check if the same bug within bubbleupnpserver can be fixed in a similar way.

Yes, a BubbleUPnP Server update is needed to fix this. There is no immediate plan for it though.

 

Additionally, with both programs some metadata within Denon's now playing screen on TV are missing, IF the track change is done automatically as the playlist proceeds. But they are shown IF one manually selects a new track within playlist. Missing fields are remaining time, hires icon, and bitrate.

BubbleUPnP Server sends for all tracks that missing information on the display of your Denon. So it looks like a Denon bug on track changes with gapless control.

There is nothing I can do here.

 

One final question w.r.t. stopping playback from bubbleupnpserver if one switches of the Denon AVR or changes input  (only standby, network connection still active). Will that automatically do pause? If not I'd suggest that bubbleupnpserver should automatically set its current playlist to pause. It might be continued later from bubbleupnp controller by pressing play. There must be no automatic start of playback when Denon renderer is switched on.

BubbleUPnP Server does not know about your Denon is going into standby or changes input. Though, if when you go into standby or change input resulting in the Denon stopping playback on its own (as I suppose it does) and it notify the app of it, BubbleUPnP Server would see it as a track transition change and trigger playback of next track (is it what happens?). In that case, you can stop playback using long-press on the Play/Pause button in Android BubbleUPnP, in the 'Now Playing' tab, prior to switching source of putting the Denon into standby

[Michael Waldor]

Thanks for the clarifications:

bubbleupnpserver update: I hope that you will include the Denon bugfix sometimes within the future ...

Missing metadata: In agree with your opinion that it sems to be a Denon bug. But depending on context (of bubbleupnp) sometimes ALL metadata is available, it is only missing for automatic changing of tracks. Using Qobuz app (or other apps) metadata is always visible.

Renderer standby: Of course it's clear that I might stop playback within bubbleupnp. My suggestion is to automatically stop an bubbleupnpserver playlist if the renderer becomes unavailable. I guess that's a feature request for bubbleupnpserver.

Regards, Michael

[Michael Pujos]

Hi,

On Friday, January 9, 2026 at 3:52:09 PM UTC+1 Michael Waldor wrote:

Thanks for the clarifications:

bubbleupnpserver update: I hope that you will include the Denon bugfix sometimes within the future ...

I will look into making a BubbleUPnP Server update but no promise when that will happen (though it is not months away).

 

Missing metadata: In agree with your opinion that it sems to be a Denon bug. But depending on context (of bubbleupnp) sometimes ALL metadata is available, it is only missing for automatic changing of tracks. Using Qobuz app (or other apps) metadata is always visible.

I believe, it is an issue that only happens with gapless control. In that mode of control, first track (or whenever you manually initiate playback of a track) use the standard UPnP command to play a track,

and subsequent tracks use a gapless specific command. I think the Denon does not properly update the metadata on its display with subsequent tracks specified this way (gapless specific) for a reason only Denon knows about.

Again, there is nothing I can do about it.

Renderer standby: Of course it's clear that I might stop playback within bubbleupnp. My suggestion is to automatically stop an bubbleupnpserver playlist if the renderer becomes unavailable. I guess that's a feature request for bubbleupnpserver.

When you put your Denon on Standby while it is playing a track, does BubbleUPnP Server wakes your Denon immediately to play a track ?  

[Michael Waldor]

I just did test it. First I've started bubbleupnpserver when I was watching TV. As soon as bubbleupnpserver was up and running my Denon did switch input automatically from TV to Heos/network (not an expected/wanted behaviour). Next I've startet bubbleupnp to start playback (it still remembered my last playlist on Qobuz) - works with the known issues. Then I've switched off my Denon AVR during playback. Sadly, it was powered on immediately. Playback continued, but without sound. I had to engage a fresh playlist to get again sound output.

Next I've put playback into pause. Then I could switch Denon's input as wanted. Also switching off the AVR did NOT power it on again. Thus bubbleupnp/pause is the correct way to "stop" playback of bubbleupnp/server.

From my (user) perspective: I use bubbleupnp on an Android tablet to select any (Qobuz) album to be played as a whole. Then I close my tablet to listen to the music using the IR remote to control volume. And I'd like to pause playback sometimes without tablet. Heos or Qobuz apps both support this. But I really prefer the GUI of bubbleupnp... And that's the reason for my feature request - powering off my Denon should automatically engage pause of bubbleupnp playback (instead of powering on my Denon). Of course - even better - bubbleupnp should respect all navigation controls from Denon renderer, but pause is the most important one from my perspective.

Denon has a nice documentation of their Heos API see https://rn.dmglobal.com/usmodel/HEOS_CLI_ProtocolSpecification-Version-1.17.pdf Maybe that helps?

Regards, Michael

[Michael Waldor]

I did some additional testing w.r.t. Denon AVR & bubbleupnp (no bubbleupnpserver):

1. Denon mainZone off. Empty playlist within bubbleupnp. Now selecting some Qobuz album. It becomes visible within play now, but volume is set to 0. Great! When I now press play, mainZone is switched on, volume is cranked up to the previous volume. Again great! But my Denon needs some seconds, till it can play sound and might report ready to bubbleupnp. Sadly that's interpreted as a skipnext by bubbleupnp which is played.

Next I've stopped playback and cleared the playlist. Then I've closed bubbleupnp. Nothing happens. My expectation would be that Denon mainZone is switched off by bubbleupnp on exit program.

Switching of mainZone manually works fine, it is NOT powered on by bubbleupnp.

2. mainZone off, zone2 on (to listen with my headphone amp connected to zone2), input Heos. Starting bubbleupnp and playing some Qobuz track. Works fine.

Same start condition, but input zone2/Tuner. Starting bubbleupnp will unexpectedly power on mainZone. Instead it should switch to zone2/Heos input. I do workaround here by selecting Heos input myself.

From my perspective I'd be happy if bubbleupnp would never try to power on/off my Denon renderer. Sometimes playback volume stays zero after such power cycling and cannot be controlled by bubbleupnp. Only creating a fresh playlist helps.

[Michael Pujos]

BubbleUPnP has no concept of renderer specific features such as zones and standby.

The only thing available is standard UPnP commands: Play/Pause/Stop/SetVolume.

What the renderer actually does with these commands is opaque to the app: it could wake up, switch zones, etc: the app has no idea.

A possible annoyance is if a track is playing and the renderer emits on its own a STOPPED event to the app to signal playback has stopped (for example if you put in on standby, switch zones, ),

the app will interpret it as a track change event and initiate playback of next track, which may be unwanted.

This can sometimes be worked-around by enabling 'More > Settings > renderer settings > (pick renderer) > Detect external stop'. But careful with this setting as it can break track advance.

Also that issue cannot happen if you stop playback (long-press on Play/Pause button in the Now Playing tab) prior to doing something to the renderer external to the app (switching zones, standby, ...)

[Michael Waldor]

Thanks for your quick reply. Now it's clear that you by principle/design cannot handle all these undesired side effects on my Denon renderer.

Sadly, I cannot activate the option ' Detect external stop ...'  - it is greyed out for my device.

Nevertheless I'll continue to use bubbleupnp because Qobuz app will have a connection dropout about once per hour. I hope to workaround that by bubbleupnp with 'Proxy Qobuz title' engaged.

Regards, Michael

[Michael Pujos]

On Tuesday, January 13, 2026 at 2:49:11 PM UTC+1 Michael Waldor wrote:

Thanks for your quick reply. Now it's clear that you by principle/design cannot handle all these undesired side effects on my Denon renderer.

Sadly, I cannot activate the option ' Detect external stop ...'  - it is greyed out for my device.

Yes it is disabled when 'Gapless control' is enabled for the renderer. 

[Michael Waldor]

Just a kind reminder ... please consider to update bubbleupnpserver. Currently I use bubbleupnp as controller on my Android tablet streaming towards Denon AVR with Qobuz proxy being enabled. Works fine and without dropouts, but sends all data twice across my WLAN without need.

Thanks, Michael

[Scott Owen]

OpenHome renderer fails to start playback from cold/standby — Denon CEOL RCD-N12DAB

Setup: BubbleUPnP Server running in Docker (host network mode) on a Synology NAS, with an OpenHome renderer created for a Denon CEOL RCD-N12DAB. Controlled via the Android BubbleUPnP app. Network Control is enabled on the Denon. This setup worked reliably for about six months after initial setup, then began intermittently failing to start playback, and this has persisted for well over a year now.

Main symptom: When starting a playlist while the Denon is in standby, the app returns an error along the lines of "current state of the service prevents that action" (the full text disappears too quickly to capture). If I wait roughly 10-20 seconds and retry the same action, it works — by which point the Denon has finished powering on. This looks like the renderer rejecting the Play command (likely UPnP error 701, "transition not available") because the Denon hasn't finished its wake sequence yet when the command arrives.

Related symptom, same underlying cause I suspect: on some cold starts, instead of the error above, the first track of the playlist is silently skipped — the Now Playing / Playlist view shows the whole album queued with the "play" cursor already sitting on track 2, and nothing actually plays until I manually hit play. This matches what another user (Michael Waldor) described with a Denon X6400H in the "bubbleupnpserver & Denon Heos" thread from January 2026 — the Denon's wake latency apparently getting misread as a track-transition/stop event.

Steps to reproduce:

1. Let the Denon CEOL go into standby (or power-cycle it).
2. From Android BubbleUPnP, select an item and start playback on the OpenHome renderer immediately.
3. Observe either the "current state of the service prevents that action" error, or the playlist silently skipping to track 2 without playing track 1.
4. Wait 10-20 seconds, retry — playback starts normally.

Timing note: as best I can tell, this started misbehaving somewhere around November/December 2025 — which is roughly when BubbleUPnP for Android went to v4.6 (Nov 18, 2025) and Denon pushed a HEOS firmware/app update (v3.88.532, Nov 19, 2025), within a day of each other. I can't confirm either update is the actual cause, but the timing seemed worth flagging in case it matches something in your own release notes.

Is there any way to add a short retry/wait period before giving up on a Play command when the underlying renderer reports it's not ready yet, specifically for slow-to-wake devices like this one?