Artist images very slow to appear

Roon Core Machine

ROCK on NUC5i3MYBE with 8GB and 240GB SSD

Networking Gear & Setup Details

Wired, with 1Gbps internet connection

Connected Audio Devices

A number of Roon endpoints

Number of Tracks in Library

Circa 97k tracks, 7k albums

Description of Issue

Since a full rebuild of my Roon Core database necessitated by the action of the B880 update, I have found the dynamic image presentation to be lacking.
Many times I am presented with a blank screen like this

This feels like a retrograde step from B831 regarding how artist images and album artwork is displayed.
There have been several occasions were the artist has been searched for, an album selected, the music is playing BEFORE the associated images are displayed. This is not the media rich experience, with lots of images displayed, have got from Roon to-date (been a user since the 1.0 release).


The only thing left is perhaps DNS performance? Have you tried using or etc?

With Roon already known for causing excessive DNS queries, this change is likely to make things worse.

I have two DNS servers running on my Synology NAS servers and haven’t seen these complaints in my system (might just be lucky)

Do you have the ability to run a DNS servers (not that you should have too).

Was on have returned back to my ISP’s own

I don’t think the DNS suggestion is even relevant anymore, as changes in 880 (eg, cached images) I think we’re made to reduce network activity. I think you’re better off pointing local devices to a local DNS server - in most cases the ISP router, and the default anyway if you’re using the ISP router for DHCP.

Mike that’s what a caching DNS server does.
Mine point to and and it’s saves all the server’s looking things up individually.

Interestingly the FBI and US Cert were recommending this year to only allow your DNS server’s to get DNS addresses and block everything else, which is what I have done in my enterprise environment’s for 20 year’s

There is almost always a reason to have one set up if you can easily do it. Based on my reading of another thread where someone from Roon posted about getting image’s remotely it made me think even more about the need for one

Of course I might have mis construed what was written

1 Like

3 posts were split to a new topic: 50% of my artworks are missing

This happens because Roon changed the way artworks is downloaded and stored.

See the response to one of my post here Shrunk database size after 1.8 build 880 update - #3 by brian

I prefer the older method. Although it may take more space to backup. Or Room could just backup the database but would still download all of the artworks whenever there is new install or recover from backup.


That’s the one I was referring to but was too lazy to link :+1:

Thanks for the feedback, all.

Going back to the old way is not in the cards, but we can definitely look at experience issues caused by these changes and work to improve image display performance where it’s currently lagging.

First, to be clear, the changes that we made here were not aimed at shrinking backups. That’s just a pleasant side effect.

In the old world, we downloaded artwork when importing your library, and then updated it on a regular basis (more or less, downloading it over again) to keep it up to date. This was problematic for a number of reasons.

During the initial import of a music library, a large portion of the time required to import the files was spent downloading artwork, and much of that artwork was viewed infrequently or not-at-all. It was a big waste of bandwidth, and a waste of our users’ time making them wait for this when first using the product.

To keep artwork up to date, the Roon core used to update each image file every 7-14 days This means that at some point during the week, the Roon Core would wake up and start…well, doing stuff. CPU usage happens, more network activity happens, fans may turn on. For people with large libraries, this background work could be running a lot of the time. This is something that many people have complained about, and something that we were becoming increasingly uncomfortable defending as reasonable behavior.

Another problem with the old scheme is that the Roon core had to guess about the artwork resolution too early, instead of being able to take into account what a given display device needs. We used to download images in two sizes, “small” (roughly 256x256), and “large” (roughly 1024x1024). This was fine 10 years ago when almost all screens were roughly 130dpi, but today we have “retina” displays, 27" 4k monitors, etc, and this one-size-fits-all approach was not working. Sending low-res images to high-density devices was making Roon look blurry or pixelated, and sending high-res images to low-density devices would in many cases cause it to perform badly.

So we needed to move to a system where display devices can request exactly what they need. For people with diverse display devices, that could require up to 6 pre-scaled copies of each image for different devices / display use cases. Downloading all 6 possible sizes that any device could ever ask for in advance is not an option–it would increase the problematic resource usage that I described above threefold.

Finally, the 7-14 day update interval was pretty long, and shortening it, again, acts as a multiplier on the resource usage associated with artwork. It’s especially offensive in an environment where we are asking users to contribute images to Art Director. In the new world, images should take less than 72hrs to flow through all of the various caches and become visible in-app.

The way Roon handles images today is essentially the same as how every other app that you use handles images. They are fetched on the fly at view-time and cached in various ways inside of the application to speed up future views. In the backend, we use a content distribution network to globally distribute the images and make sure that load times are fast for everyone. In most cases it works very well and the experience difference is minor. We can work to improve the other cases.

I think it’s better for everyone that we stop trying to manage huge pre-downloaded repositories of images on the Roon Core. These changes will make the whole product perform better, more efficiently, and more reliably by removing work and complexity, and will make images look better and load optimally on all devices.


Thank you for the feedback of why you deem the change necessary.

However its not just lagging on an occasional basis, EVERY time I open an artist, search for an artist there is no artwork initially displayed.
So this method is not working, it is broken. It may have worked for you during development & testing, but it is not working once deployed within your customer base.

Sorry I disagreed, I would prefer to have existing images displayed when I pull up the artist, then have to wait for them to load.
As such I disagree with “more efficiently”, when I get blank artist images, “makes images look better”, they are empty and blank, how is this better? “Load optimally”, I want them available when I search for artist, not once I have selected the artist and then have to wait for the images to be downloaded.
That’s why I have a ROCK server to manage my library and the metadata associated with it. It, as a server pulls download the images, in preparation of when I want them, so they don’t to be loaded ‘on-the-fly’ from a remote server and subject to network latency.
If I wanted a cloud based service, I would have subscribed to one. That’s not what Roon should be, a way of managing your own personal music library, individualised for your purposes, not a high-end Spotify!

Please this is a user giving you feedback on your product, at least have the respect to acknowledge feedback when you get it, instead of cancelled subscriptions and customers going elsewhere.
I presently have a better experience from Asset UPnP server running on a RPi2, from 10-years ago, and the latest version of the Naim UPnP Controller app.
At least I haven’t had to rebuild that database from ‘afresh’!


Please this is a user giving you feedback on your product, at least have the respect to acknowledge feedback when you get it

Sorry for quoting myself, but it seems that you missed both the acknowledgement of feedback and the acknowledgement that there are some issues in my post:

Thanks for the feedback, all.

In most cases it works very well and the experience difference is minor. We can work to improve the other cases.

With any large architectural change like this, there are going to be some rough edges to work out for a few people.

When I use the new stuff, it’s not just not-lagging on an occasional basis either, it’s great every time, and essentially indistinguishable from what we had before. This is what it looks like on my end. I did not pre-load or pre-cache any of these pages, btw–

So that tells me that there’s something different between your environment and mine. It’s my hope that we can figure out a way to make yours work just as well as mine does here.

If you have a minute, I’d love to see a similar screen recording of your experience so I can start to get a feel of where the delays may be happening.


I might be missing something, but in what way has your feedback not been acknowledged?

Surely this is such an acknowledgment.

EDIT: Forgot to say thank you to @brian for you detailed and informative post.


Really only a statement you can make for your own situation, you certainly can’t make that statement for my situation.

This is not to say you don’t have a problem that Roon will attempt to resolve if possible but it’s just not a complete and true blanket statement.

1 Like

The response was an explanation was of why it had been changed, and no acknowledgement that it may not actually be working once released.

This is on the back of the B880 release, that halted my Roon system dead in the water, with no recovery offered, other than begin a completely new database build.

Also with the previous release the impact of the Volume control for endpoints with Fixed Volume controls, was I had to stop using Roon on my iPhone, as it kept muting the volume and I was missing calls and alerts, even though none of my iOS devices were configured as endpoints. I still have an open Support ticket, unanswered, with regard to Roon interrupting Airplay based playback.

So I now a new database and lagging images every time I load an artist, and get

In the past I had an issue with album art promptly populating. Roon seemed to have fixed the issue but it has resurfaced. It’s not on my end. What’s up with this Roon support?

I have the same issue today as well. Thanks

Sorry you are experiencing this issue as well. Hope they remedy soon. Best New Year wishes…

This is precisely an “acknowledgement that it may not actually be working once released” - at least for certain users.

1 Like

this video of lagging artwork since 880 is very similar to what is happening on my iPad, except that once I have completed the scroll-through, the lagging sometimes happens again (I have a NUC8 core wired to a regular switch). Appreciate the point that has been made that the way Roon used to manage artwork was no longer fit for purpose, but the change that Roon has made has, ironically, substantially de-graded performance in my case. I use the “show more covers” option for my album artwork so the lagging effect introduced since 880 is very noticeable. I am in the UK with an 80Mbit/s download speed.

1 Like