There appear to be quite a few issues regarding DNS with Roon these days.
I too find that the ‘Discovery’ page loads very slowly these days (I’m running Roon Rock on an i5 NUC with 8Gb RAM). However, my main issue is with intermittent missing metadata (such as album artwork or Background photo) when running Roon Radio.
I would appreciate a solution that does not simply comprise a suggestion to "try switching your DNS and see if that works".
The DNS related issues as I understand them in regards to Roon at least, often relate to your DNS servers returning IP addresses for geographically near vs geographically far remote servers, and if they are far, this can especially make a difference when streaming content from Tidal (and possibly Qobuz) content servers, eg latency at the beginning of streams and moving to next track, and ability to keep buffers full.
In my case with my current ISP, the DNS lookup for the Tidal content servers returns a set of IP addresses for Tidal’s geographical distributed content caching servers in my country (if I recall its on Akamai’s infrastructure), and so Tidal based playback starts fast and buffers with no problems. I did have a problem a couple years back with my previous ISP where sometimes (but not always) I would get directed to Tidal content servers elsewhere on the planet and the additional latency causes noticeable pauses, and that issue was fixed by pointing my Roon Core’s DNS client to either Google or CloudFlare’s DNS servers which usually return addresses for geographically closer servers.
For the Discovery page however, the culprit (in my case at least) appears to be Roon’s own cloud based API endpoints that the core server is calling to get information required for the Overview page. These are unlikely to be geographically distributed, and indeed they appear to be running out of a single country, ie the USA.
For example, for the remote API calls from the Roon Core in my earlier log extract:
api.tidal.com returns 4 IP addresses, all based in Florida, USA
tidal.roonlabs.net and discover.roonlabs.net both return the same single IP address, based in Missouri, USA.
That’s using my ISP’s DNS servers, but I get the same addresses if I tell dig to use Google’s or CloudFlare’s DNS servers for those 3 DNS address lookups. So the “DNS fix” is unlikely to improve things in the case of the Overview page’s performance being delayed by those remote API call’s.
It is more likely a combination of the large physical distance (in my case) between New Zealand and USA, as well as the relatively slower response times for those specific API calls on the API servers at roonlabs.net itself.
There could be a number of reasons for those remote API calls to be relatively slow. For example, a capacity issue, or side effect of whatever is in my Tidal profile which the remote Roon API endpoint has to process, and so on. Perhaps the remote Roon API end point is on-calling a remote Tidal API endpoint, and has to wait for that response to return the result back to my Core. So many possible reasons. @dylan noted many months back in this thread that there are known performance issues in some specific scenarios with these 2 pages, perhaps the behaviour some of us are seeing here is the same issue, perhaps its something else. @noris posted in August that there may have been some improvements in Build 610, however it seems many of us are seeing issues still on these 2 pages, so perhaps there is more than one thing at play here.
Whatever it is, as you might have noticed, these things are sometimes complicated 
. I work in software development, so I can appreciate there is a lot of complexity in software architected and built the way Roon is, and so I can empathise with the Roon developers, however it would be great to have these issues resolved, as this behaviour has been around for a while and there are likely many people just putting up with it, but it is frustrating them when using Roon each and every day. Hopefully it is on a Roon product owner’s todo/backlog already and will get looked at in due course.
I certainly believe that these things can be complex - I used to work in software development myself!
However, my frustration with my particular issue (Roon Radio intermittently but frequently failing to deliver metadata such as album details/artwork etc) stems from the fact that Roon Radio (which is one of the Roon functions that I use most often) worked absolutely flawlessly for a year or so after I first subscribed before the problem first manifested itself immediately following a specific Roon build release.
The problem went away after a subsequent release, but reappeared several months later immediately following a further build release. Over this entire period of time, my home network, ISP and ISP DNS have remained unchanged, logically pointing the finger at Roon’s software build implementation as the root cause of the problem .
IT appears to me that there is a solution to my issue (that has been implemented in 2 specific Roon builds), but that there is also a regression problem that results in that solution being lost by subsequent releases.
I should add that with the exception of the recent ‘Discovery’ issue (which in my case means a relatively short delay in the Discovery page appearing on my screen), Roon has otherwise worked flawlessly for me. The Discovery page displays full metadata when it does appear, as do all other functions apart from Roon Radio.
What is so different about the specific way that Roon Radio returns metadata - there really is very little metadata to return by comparison with other Roon functions.
Using Cloudflare or Google’s DNS on my system is consistently slower to resolve streaming services than my ISPs service. Roon supports insistance on getting people to change to Cloudflare or Google annoys me as it is not the route to fixing this in most cases. I do believe it’s their internal infrastructure that’s the route of the issue. It was with slow searches back at the launch of 1.6 the shift to their cloud infrastructure and it took them way to long to admit it was the issue as it did not seem to affect everyone and there was a lot of finger pointing at people’s local network setups, which is another annoying habit of issues with Roon. To me it feels like the backend just isn’t up to the task of filtering all this data in and back out quick enough and this causes these issues and with some ISPs that have poor DNS resolution likely even worse.
Just noticed some thing as well. Switching Roon profiles causes this to happen and also stops Qobuz from showing anything. Normally I have just one profile but support asked me to try a new one to test a theory on a Roon radio issue I am seeing. It did nothing for that but noticed that switching profiles causes the whole thing to slow down and again and you can’t use Qobuz either during this phase.
This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.