Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Headcool]

As it is now, JRemote seems to only cache cover-art thumbnails of items that are displayed on the screen plus a few above and below. This means if you scroll fast you will always see items without any cover and then suddenly the cover thumbnail pops up. If you scroll a longer list up and down, JRemote constantly transfers and deletes the thumbnails of the items in the list.
This is really annoying, doesn't look good and stresses the network connection.
A look into the JRiver MC Thumbnail folder (inside appdata) shows me that my Thumbnails (small).jmd is about 20MB large. This isn't that large considering there are about 7500 items on my MC-server.

I think it would be a good idea to provide an option to cache these thumbnails on my Android device

[glynor]

Mine doesn't work the way you describe.

JRemote for iOS or Android?

[hoyt]

I can confirm mine does this on Android.  You can see the thumbnails loading if you scroll quickly down the page as the disc thumbnail changes.  It seems like it loads the thumbnails once you stop scrolling for a tenth of a second.

[kensn]

I would agree on an Android platform that a large cache would be a nice option.

Ken

[glynor]

Ahh, must be an Android thing.

In iOS, it does have to cache them once, but I've scrolled through some really big lists, and it keeps them all cached (even after you quit and re-launch the application).

[Hendrik]

We use the automatic cache of the image processing framework we use, which isn't very customizable, but does a basic job. Maybe at a future point we might change that. But much more important things to do.
FWIW, its unlikely that it will ever pre-load the images for an entire folder, as that is potentially unnecessary data usage and cpu load, so if you scroll through something for the first time ever, it will not have the icons immediately, no matter how large the cache is.

[Soul_Rvr911]

We use the automatic cache of the image processing framework we use, which isn't very customizable, but does a basic job. Maybe at a future point we might change that. But much more important things to do.
FWIW, its unlikely that it will ever pre-load the images for an entire folder, as that is potentially unnecessary data usage and cpu load, so if you scroll through something for the first time ever, it will not have the icons immediately, no matter how large the cache is.

Hendrik, I don't know what image processing framework you use, but in eos I'm using Volley. One thing I've noticed about all of MCWS's HTTP responses is that they specify no caching in the response headers (i.e. Cache-Control: no-cache), which prevents Volley's - and other HTTP libraries, I'd assume - automatic response caching from working. I imagine the reason this was done is because the library can change, and therefore so can the responses. But if MCWS was intelligent about sending response headers, clients would know when response has changed and the data should be reloaded from the server.

[couchjr]

I have a different problem related (I think) to thumbnail caching for the library views (thumbnail array, thumbnail list). If I load a batch of albums into MC's main library, and then connect using JRemote, all is fine. If I delete everything from the main library in MC, and then delete everything from the "Removed database" smartlist, and close MC (and JRemote) MC starts with a clean slate when I reopen it. If I then connect again using JRemote, however, even after having closed it first, many if not all of the cover thumbnails from the first version of the library remain visible in the library views along with the new albums. But the album names only reflect the new library contents, so the wrong thumbnails are associated with a given album name.

The thumbnail associated with each album in "Playing now" remains correct, as do the thumbnails for each track. I have embedded the thumbnail image in the tag for each track (file) as well as including a "folder.jpg" copy in the album's folder.

So I think the simple solution would be a way to flush the cache in JRemote so it wouldn't get confused, but I can't find one and I'm open to any suggestions. It's odd that the discrepancy occurs only in JRemote while all is as expected in MC.

Thanks in advance for any insight.

[couchjr]

Solved it: powering off the iOS device on which JRemote runs for 30+ seconds and rebooting seems to have flushed the cache--the main library thumbnails now accurately reflect relevant albums and are in sync with the MC library view.