Missing images on Now Playing for Roon Radio and playlists

Roon Core Machine

Intel NUC 8i5 with 8Gb RAM

Networking Gear & Setup Details

Sky Q Router and Cisco 2960 switches (default settings)

Connected Audio Devices

Linn Klimax DS/1 streamer & Sonore microRendu/Mytek Brooklyn+ DAC
Ethernet connection
Roon app on Windows 10 PC & iPad Air

Number of Tracks in Library

Approx 30,000+ tracks

Description of Issue

The metadata problem I am experiencing was eventually resolved by a fix shortly before the roll-out of Roon release 1.8. Unfortunately it has started recurring a number of weeks ago.
The problem I experience is that tracks played by Roon Radio (or as part of a mix) are intermittently (but not always) missing metadata. The missing data can be album or artist details or artwork, sometimes all of these.

I will post some screenshots to illustrate this.

This irritating problem was one I experienced for approximately a year until it was fixed just prior to the 1.8 release. After it was fixed, the problem completely disappeared up until a few weeks ago. I have many posts (prior to 1.8) over the last few years illustrating the original problem. New screenshots to follow.

Here are some screenshots to illustrate the problem:

As you can see from the first screenshot, the track that Roon Radio is playing is “Partly on time” by Kinloch Nelson. However, when I click on the Roon Radio selection to view the album and associated metadata, I obtain the completely blank page in the second screenshot.

Here is another example when running a Tidal Mix playlist:

In screenshot 1, you can see that the track playing is “American Woman” by The Guess Who. In this instance screenshot 2 shows that some metadata is present (in this case lyrics), but album and artist details are not returned.

This happens frequently, but with some selections all metadtata is displayed correctly.

The last time I had this problem, it was suggested by support that the problem might be related to my DNS server, and that I should switch to a different DNS server. This is something I could not do because of my broadband provider’s rules. However, the problem was resolved by a Roon fix shortly prior to release 1.8.

Has a regression bug relating to DNS and metadata retrieval been re-introduced in the past few weeks?

It’s an annoying problem that makes it difficult for me to identify tracks/albums being played by Roon Radio or playlists. Where I see/hear a track I like, It also makes it much more difficult to add the appropriate albums to my music library. It’s no longer a simple click on an “add to library” link! I would appreciate a re-fix sometime soon!

@support, this report was moved to #support:metadata-issues, but I think it’s now being overlooked. Can someone reach out to the OP.

I’m not really affected by any of the bug fixes or new features that have been released in Roon1.8 (Build 831).

However, I am dramatically affected by what appears to have been a change in the way that Roon handles DNS that seems to have been implemented (or regressed) recently around the time of the past couple of build releases.

I had a long term issue relating to DNS prior to the release of Roon 1.8 that resulted in screen metadata (intermittent and varied from track to track) being missing from tracks played by Roon Radio or occasionally from playlists. This was resolved by Roon support very shortly prior to the release of 1.8, and it has been 100% fine up until recently.

However, a regressive change appears to have been made at some point around the last couple of 1.8 builds, because the issue is now back to what it was prior to the fix. I have raised a problem report in the ‘metadata issues’ part of the ‘Support’ section (with example screenshots), but no response of any sort from the Roon Support team at all so far to acknowledge my post.

In your support post you mentioned that you can’t change the DNS settings on your router, but have you tried changing to a different DNS server on your NUC and Windows machines?

That means using a fixed IP for rocks network settings which is not necessarily a good thing at all one should keep to DHCP and reserve in router to avoid more issues. You can’t set DNS individually it’s all or nothing with Rock. I have noticed some issues with the music sharing links not always connecting which is far more frequent on this release. This happens regardless of DNS service I use but could be related to hmacks issue.

1 Like

I hadn’t realise you couldn’t change the DNS settings in Rock. The only other solution I can think of, with respect to changing the DNS, would be to introduce an additional router into the chain, relegating the ISP’s box to modem duty.

You can change them it’s just you can’t change just them as it goes into manual setup mode for it all. Something they should consider for Roon OS 2.0 really given they are always saying to change it but many canr or don’t have the knowledge to .

Using a separate router is not always possible with supplied gear from ISP. I am lucky that I can but many only allow you to use their kit and it’s a combined modem and router and lits ocked down, likely to mitigate support calls.

I was under the impression that most ISPs allow it (in the UK at least), but it does seem as though some make it more difficult than others.

Yes - my ISP locks down DNS.

I have tried specifying a different DNS in Windows 10 (to Google’s DNS servers), but absolutely no change - metadata still intermittently missing. The DNS settings are no doubt changed back to the ISP’s DNS servers by the router anyway.

Rood must have made a DNS change on their side immediately prior to the 1.8 address, but have now overwritten whatever that change was in their recent updates.

Perhaps pi-hole with a spare raspberry pi?

1 Like

Its worse than that. There are ISP’s which don’t respect your internal settings of DNS and still routes through DNS servers chosen by the ISP.

1 Like

Which I’m pretty sure is the case for me. However, I don’t blame my ISP. I can understand why they don’t want to alIow users to specify any DNS server whatsoever. I have never had any DNS related issues with any application I use other than Roon, and Roon are obviously able to surmount the DNS related problem at their end given that they have done so on a couple of occasions in the past. Unfortunately, the ‘fix’ has now been applied and subsequently regressed a couple of times over the last couple of years. Last time the issue persisted for the best part of a year before it was resolved. I very much hope that Roon will re-issue their fix more quickly this time round.

1 Like

Just checked mine - running a bunch of Deco M9’s behind a Virgin Media Hub 3 - and it looks as though I’m using the DNS server I’ve set for the Decos. Thanks for the heads up @Rugby

I’m in the UK on VM too and I don’t think they interfere with DNS. Years ago I used to use OpenDNS on the children’s computers, which worked well (wouldn’t have if anything intercepted DNS lookups). You could do a traceroute in a DOSbox/terminal to verify the path for a DNS lookup?

1 Like

Hi @hmack,

I’ve tagged @support to follow this up for you and merged the subsequent discussion so it’s all in one place.

Perhaps it’s time for Roon to introduce the “performance and connectivity toolkit” needed to get hard facts from any installation?
I’m talking about TCP-connect times between Core, controller and endpoints, route to .roonlabs.com and perhaps the streaming service(s)of choice, processing capability for DSP and any other facts that might be useful for support. Hell, it may even populate the requested info in the Support part of the forum when creating a new topic.

There a lot of talk, advice and tips on W.A.'s but seldom based on some sort of checklist and therefore hardly reusable and helpful in building a knowledge base (At least from my perspective).

1 Like

Thanks for this!

1 Like

Still no response or acknowledgement from @support of my original post!

Has there been a change implemented at the Roon end as to how Roon deals with DNS - perhaps a change to the number of re-tries or time-out settings which could have resulted in this problem returning recently (having been resolved just prior to release 1.8)?