Sounds good, as the issue feels deeper than just tweaks & fine-tuning around the edges.
Happy to test once you have something deployable
1 Like
Any fix for this? I thought a hotfix would have been rolled out by now…
EDIT: I say hotfix, because this was never an issue for 4 years and then one update rolls out and it’s an issue… why is it so hard to correct?
Presumably because of what @brian said earlier:
there’s one more change that I’d like us to make before we put a new release in front of you guys. It’s a bit more complex and involved than the performance optimizations that we undertook last week
Because it wasn’t a bug, it was a consequence of some re-architecture. We couldn’t roll it back without breaking lots of other stuff, so we had to push forward with a refinement to the new approach. I explained the architectural change in detail higher up in this topic.
It’s in QA testing now, and going well. It will be out soon.
3 Likes
Just ran into this issue, helping a friend.
I was able to resolve it for about 15 seconds each time I changed DNS servers on the Nucleus+ web interface. At first I thought this was hitting a rate limiter with the initial DNS, but that would be crazy given this library isn’t the large. Based on Brian’s comments, I’m guessing the DNS temp fix I found is a red herring and unrelated. I guess we wait for the fix.
I complained about artwork lagging months ago in the ios scrolling lag thread,the whole roon experience for me was destroyed when 1.8 was first put out,they seem to be putting all there time into features that we don’t need or want than trying to fix the serious problems theve put on us,the lag and stutter on my ipad pro/iphone 13 pro max has been going for 2y now,all we get from them is that there working on it,I now refuse to give them my money,this is why I cancelled
I wasnt seeing this issue at all, until yesterday.
A deep, slow scroll into my Artists on an iPad Air 2 remote. The first 2/3rds of the artist images all loaded as I scrolled with no problem. But then I reached a point from where no images would load at all. I could keep scrolling and see nothing but grey circles. Scroll back up and the previously loaded images would still appear, but from the failure point onwards literally nothing at all.
The issue persisted into each artist page as well. If I clicked into one of the artists with a grey circle it would not load any images on the artist page either.
Is this the issue being discussed here? It doesnt sound quite the same, my images would not load at all after a certain point, they werent slow they were missing. I was wondering if it might have been a hard cache limitation on my admittedly pretty old iPad remote?
Hi all,
Build 898 includes a new approach to solving this problem. Once you’ve updated your core+remote to Build 898, try it out for a few days and let us know how it feels.
We did some performance optimization to the image loading process which made things 2-4x faster end to end depending on your hardware (biggest benefits for weakest hardware).
In addition, we changed the caching model so that it’s willing to display a “stale” cached image during the loading state instead of making you wait for it. In the rare case where the image changed on our servers, it might flip to the new one a fraction of a second later.
This means that over time, your core and remotes will build up a semi-permanent cache of artwork that can be displayed without speaking to our servers, which should have similar “local network speed” properties to how Roon worked before the update in December.
Note that we still are not pre-loading images at library import time and do not plan to change that (for many reasons, which were discussed above in this topic). In in day-to-day use, once you’ve browsed around a bit and populated those caches, it should feel very close to what was there before the updates in December, and most importantly, it should stay that way and not feel like it’s depopulating every couple of days.
Thanks for all of the feedback on this, and let us know how it turns out for you once your devices are updated to build 898 and you’ve had a chance to live with it a bit.
11 Likes
Thanks, already works well for me (remote on iPad 5th gen).
Ok
The first impression looks good
Updated core and client on my iPad 5th generation, much better. Much improved. I don’t know about streaming, but all my files are local. The images used to be slow / not shown. They all show much faster. Almost or similar to pre 880 build.
Thank you.
It seems the images are not permanently cached, because this morning all images were loading again. Faster as in the the previous build but noticeably one by one image was loaded.
After this initial loading images seems to be in some kind of cache because you can jump from A to Z and images are immediately there.
Edit: This was probably I updated the iPad app in between and therefore images were loaded again. This evening all images were there right from the start of the app.
Thanks Brian! This really makes a difference (glad I have ‘weak hardware’ 
). Loading times for the albums are as quick as before this all happened. If I’m experiencing lagging the coming days, I wil let you know but I don’t expect that to happen.
It might be a bit better, but some low-hanging fruit regarding image loading/caching is still not fixed it seems.
E.g. when scrolling through the album list from top to bottom, but only stopping at the bottom should preload all images when “passing by”, but it does not. Scrolling from top → bottom (wait a bit) → e.g. the middle will still cause images to not instantly appear.
And there seems to be no eager loading. For instance if you are scrolling slowly, it is quite easy to guess what images are needed next (even without any ML etc), but they don’t seem to load until they are explicitly shown on the display.
I recently returned to roon, just after the 1.8 release. And I am just terrible dissapointed, since the main reason for me to use Roon and not any other solution have previously been the image loading performance.
So far, b898 seems to have significantly improved load times for me (iPad 7th gen). 
Hi Brian,
Not sure if my NUC5i3 running ROCK, iPad Pro 9.7, Dell i5 XPS13 is classed as weak hardware, but the backup iPad 2 Mini, at nearly 9-years old, and the HP 2540p i7 laptop, at over 10 years old, granted is as such.
However all are benefiting from the revised image delivery solution.
The stale caching is an excellent solution, and as you say, if the cached images are not being updated within the Valence server, there is no requirement for them to be updated in the cache.
Plus an ‘old’ image is still better than no image. And from what I have seen when a cached image is updated and replaced, it is instantaneous once the new image has been served in the background.
Overall the feel of the Roon Remote interface is back to being ‘snappy’ and responsive.
Is there any persistent applied to the image cache? Is it included as part of the Core database stored on the SSD or just an in-memory cache? And is it part of a backup/restore process, if this was required?
So for me I run my Roon Core on ROCK as a dedicated server operation 24/7 and behind a UPS, so Reboots/Power cycles are infrequent (potentially months apart), so in time the cached images could be there for all frequently played artists.
1 Like
I think there is a backend issue at the moment, so might be a reason.
1 Like
Yup…
Thank you for your patience and understanding 
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.