Metadata not displaying during playback in dCS stack with Nucleus+ (ref#R8LIOI)

Support
21

Hello @Charles_Craiglow

Thank you for your patience while we worked through this. We’ve now completed a thorough analysis of the diagnostic logs captured from your system, and we have a clear picture of what’s happening.

The metadata loss on your Vivaldi Upsampler is caused by a display session disconnect that the Vivaldi firmware does not recover from automatically.

When Roon starts playback on the Vivaldi, it sends a request_source command that includes a URL pointing to Roon’s built-in display page, hosted directly on your Nucleus+:

request_source → url: http://192.168.7.72:9330/display/2/?endpoint_id=…

The Vivaldi’s internal browser opens that page and maintains a live WebSocket connection back to the Nucleus+ to receive ongoing metadata updates. Under normal conditions this works correctly - as you’ve observed, the very first play session after a server restart is always fine.

The problem occurs when playback is paused for more than a minute or two. During this idle period, the Roon broker service on the Nucleus+ periodically re-initialises its network listeners on port 9330 - we can see this in the logs as repeated “cloning service … localEndpoints=tcp://192.168.7.72:9330” events. This silently drops the Vivaldi’s WebSocket connection to the display page.

On the next play, Roon correctly re-sends request_source and the Vivaldi responds with {"status":"Success"} - so from Roon’s perspective everything looks healthy. However, because the Vivaldi still considers the source “selected” from the previous session, its firmware does not re-load or re-connect the display page. The page is open but dead, with no live data feed, which is why the display is blank.

This also explains your observation that the metadata briefly flashes on the Upsampler window the moment you start a track - that is the last frame of the previous WebSocket session, rendered before the connection is fully confirmed lost.

The recovery workaround (pause → reselect → Play from here) triggers a full transport teardown and a fresh session setup, which forces the Vivaldi to reload the page and re-establish the connection from scratch.

Next Steps

dCS

We’d ask you to open a support case with dCS and share this analysis with them. The fix on their side would be for the Vivaldi firmware to treat an incoming request_source as a reload trigger even when that source is already marked as selected, so that a stale WebSocket connection is detected and replaced rather than left in place.

Roon

We are logging this with our own engineering team as well. On our side, we can investigate sending an explicit close followed by a new open in the request_source sequence when resuming after an idle period, which should prompt even a cached display session to reload.

In the meantime, the fastest workaround remains the pause-reselect-play procedure you’ve already found. Setting the Mosaic app to stay in the foreground on the iPad (and disabling iOS Auto-Lock while listening) may also reduce how frequently the display session goes stale, though it is not a root fix.

We’re sorry this has taken time to track down, and we appreciate your detailed reporting throughout - it made the log analysis considerably easier. We’ll update this thread once we have word from our engineering team.

22

Vadim,

Thank you for following up on this and for the detailed feedback. It’s good to finally know the source of the problem. I’ll definitely try to get this info to dCS, and I’ll post a Reply with whatever I hear from them.

Chuck

23

Perfect, sounds good @Charles_Craiglow! Thanks again :+1:

24

Benjamin,

I’ve provided the Roon analysis to my dCS dealer who will be passing it on to dCS. He had previously opened a ticket with dCS on this issue, but we had not heard anything back yet.

As soon as we hear anything from dCS, I’ll post an update.

Thanks again for your continued support on this.

Chuck

25

Hi @Charles_Craiglow,

Thanks for your patience with this one. To narrow down where the metadata is getting lost, please try one additional specific test (even if you’ve already performed this ritual before).

Pause playback for at least 3 minutes, then resume using only the play button, without requeing the track or using “Play from here”.

Note the track you were playing and then perform your usual recovery steps. We’ll gather logs remotely to capture the incident. Thank you!

26

Connor,

If necessary, I can run additional testing per your request. However, based on Vadim’s detailed post of June 22, I thought the Roon-dCS metadata issue has now been fully diagnosed and completely understood. At least, it certainly sounded that way. Am I missing something?

Please advise. Thank you.

Chuck Craiglow

27

Hey @Charles_Craiglow,

You’re not missing anything, @vadim’s write-up on the 22nd does correctly identify the mechanism causing the metadata loss. That diagnosis stands, and it’s the one we’re taking to dCS and our own engineering team.

The reason we’re asking for one more specific test is narrower than re-diagnosing the issue: we want to confirm the exact recovery behavior when you resume with a plain play button press, as opposed to the pause-reselect-play workaround you’ve been using. Reselecting the track forces a full transport teardown, which is a bigger hammer than what a typical user would reach for. If a plain resume also triggers a fresh request_source but still fails to revive the display, that tells us the fix needs to live in how Roon or the Vivaldi handles reconnection on any resume, not just full requeue events. That distinction matters for the fix we’re proposing (sending an explicit close before the new open), so we want fresh logs captured against this precise scenario before engineering commits to that approach.

So to be clear: this isn’t back to square one, it’s a targeted follow-up to validate the fix path. Whenever you’re able to run it, just note the track and timestamp as before and we’ll pull the logs on our end.

Thanks again for sticking with this, Chuck, your reports have made this a lot easier to pin down. :raising_hands:

28

Thanks, Benjamin.

Appreciate the clarification. I’ll run the test you are requesting and report back, probably in a day or two.

Regards.

29

Hey @Charles_Craiglow,

Thanks for the update. We appreciate you running the test and reporting back. Please let us know what you see when you have the results.

30

Roon Server version 2.70 (build 1671) production.

Roon iPad app version 2.70 (build 1671) production.

Connor,

I tried to recreate the metadata issue and perform the testing you requested but was shocked when I ran into a related but completely different problem.

Track: Ectopia

Artist: Oregon

Album: Beyond Words (Qobuz FLAC 96kHz 24bit)

Date: 10 July

Time: 13:17 local time

Started playback by selecting the track in the Queue and saying “Play from here.” Scrolling in the metadata section of the Upsampler window is the garbage text “THREE_LINE_SUBTITLE – THREE_LINE_TITLE”.

Time: 13:18

Paused playback.

Time: 13:20

Restarted playback using the Play button in controls area of the Roon iPad app. Same garbage metadata remains in the Upsampler window.

Time: 13:24

Used Pause > Reselect track in the Queue > Play from here, to restart playback. No change, same garbage metadata in the Upsampler window.

Time: 13:25

Paused playback. End of test.

These results are identical no matter which track you play, and no matter how you start, pause, or restart playback. And there is no workaround that I could find. I tried all of the following: restarting the iPad app; restarting the Roon Server; upgrading all my devices to Roon version 2.70 (build 1671) production; and power-cycling the Vivaldi hardware. Nothing changes the garbage metadata that scrolls in the Upsampler window.

The situation in the dCS iPad app is a little different, however: The app now displays the correct artwork and the correct audio format for whatever track is playing. There is also a progress bar showing the elapsed time, but the ending time is always 3:25:45 no matter what track is playing. Finally, there are two lines of slightly different garbage text where you would expect to see the artist, track name, etc. – “TWO_LINE_TITLE” / “TWO_LINE SUBTITLE”.

Bizarre…

Chuck Craiglow