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 22.214.171.124 and 126.96.36.199 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
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
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.
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.
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.
@brian I am not sure that the caching is working in my system using ROCK on i7 NUC? Eg on the artist page, accessed by iPad, the images do load but one can see the slow crawl as they do so, scroll down a few pages ensuring all current images load, more images load in a slow manner, scroll back up to the top and the artist images that had loaded moments before have to reload again very slowly. Same behaviour for album covers.
Where is the caching happening, core on ROCK NUC or on the client device?
I have a very modest collection of both local and Tidal albums yet the user experience is nowhere near the previous experience where images would load instantly using the same setup.
How can one confirm that the cache is working as intended?
(In UK with 37 Mbps VDSL broadband)
That’s good for you, but nowhere near the experience i am seeing.
I don’t see the same behaviour as @simon_pepper but the whole Roon experience has gone out the window for me also.
However, your points made in the explanatory post previously are all good. Now, how do we re-instate the whole Roon experience?
Because i get a helluva lot nicer browsing experience with my BluOS library or my Auralic Lightning DS library today?
This caching in the application does not seem to survive closing and restarting the Roon client? At least, that’s the behaviour I am seeing in Roon on Windows 11 working with a ROCK/NUC Core.
At the end of the day, I shutdown my Windows PC (the Core is on 24/7), and the next day when Roon starts up, it has to fetch all the album covers all over again… The initial browsing experience with the Album Browser after startup is not very thrilling…
So the 1st and 2nd are listings of blank images under ‘Artists’
The third is some navigating around artists, banner for Roxy Music does comes up, but the Album artwork lags, clearer when viewing Blur, no banner image, the thumbnail images that ages to show, the album artwork is blank, the caching does recover the banner image, then for Grace Jones, the thumbnails and album artwork lag, and then I click on composers and another screen of blank images.
This is not how Roon worked before this change, and is not indistinguishable from how it was.
I have found the image caching does not survive the frequent iOS app crashes experienced, nor day-to-day, so what is the cache lifetime?