Print

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

[hoyt]

I setup a new device on my network running Ubuntu to use at my desk instead of my normal Mac MC25 so that I could keep it plugged in, use a better DAC, etc.  It's a pretty light powered device (1.1 MHz celeron, 4 gb of RAM), so there's no way it's going to do much in terms of video - but that's not my plan.  I got it all setup but when I use Panel, the CPUs in htop spikes while loading coverart.  When I scroll, it does the same again.  I then exit the view and come back and it repeats.  This makes for a fairly jerky experience as coverart slowly loads.

If I load up JRemote2 and do the same, it caches the coverart so that next time I hit that view, it doesn't need to ask for the files all over again. 

Is there any way that Panel could cache these items to improve the user experience?

[RoderickGI]

I would expect caching to be provided by the browser. Certainly Chrome caches image as it works. Chrome on my PC is managing 242 MB of cached images. I would hope Panel uses those cached images.

Also, I would expect the graphics hardware to play a large part in the Cover Art presentation.

[hoyt]

Does Chrome cache the images for you in Panel?  It's not doing it for me.  Even if I don't change the page.  If I stay in a single view (and then wait long enough), when I scroll back to a section which had previously had coverart show up, the console is littered with GET request that trigger my server to respond.  If I trick Chrome in the dev tools to say offline and do this process, when I scroll, no images show up at all.  If there was a cacheing process, I would expect to be able to at least scroll on the same page when offline.  The only thing in the Network tab that's coming from disk cache is the CSS and woff2 (font) files.  Everything else is coming directly from a web request.

This is the same behavior I was seeing in Safari, I just switched to Chrome as a test.

[RoderickGI]

I've never actually used the Chrome Console before, but I had a look and it is reporting the getting images in the Network tab as I scroll, with the URL used it, for example;

http://192.168.0.14:52199/MCWS/v1/Browse/Image?Version=2&Token=zbADNMrt&ID=14957&FallbackColor=79%2C54%2C183&UseStackedImages=0&Format=png

But I assumed that if the URL was used previously, and the image was in the cache, it would be used.

If I set the Network Conditions to Offline, Panel stops working.

I can see the images cached under "C:\Users\[userID]\AppData\Local\Google\Chrome\User Data\Default\Cache", and if I scroll slowly in Panel, no new MCWS calls are made and no new images are cached until I have scrolled about 50 albums. Then the server went to sleep underneath Panel, and those 50 images were still available when I scrolled up and down the Album view, until Panel decided it had lost connection to the server and stopped working.

So, yes, Chrome does cache the images and it appears that Panel uses them. But not as many of them as I would have expected. There are a lot more images in the cache than are used. It is easy to see they are Cover Art images, just by editing the file name to add the png extension, and then the Windows Explorer file preview shows the image.

I suspect the small number of cached files is a consequence of the efforts to ensure that Cover Art images are refreshed often, so now art shows up quickly. There were complaints about new art not showing up for some time, or unless Panel was refreshed/restarted, if I remember correctly.


I've got to say it is a bit of a worry seeing the following message in the Console:

VM22:1 GET http://192.168.0.14:52199/Panel/Options.xml 404 (File not found)

Is Panel itself calling a file that does not exist? Or is that Chrome calling an expected file that Panel doesn't provide?

[hoyt]

If Chrome gets an image from your cache, it should say (memory cache) or (disk cache) in the Size column, like the main page of google in the attachment.  Whereas when I hit Panel, every image downloads from my server (and I can verify that by watching the CPU spike on my server).

Is that not what you're seeing? 

[hoyt]

I suspect the small number of cached files is a consequence of the efforts to ensure that Cover Art images are refreshed often, so now art shows up quickly. There were complaints about new art not showing up for some time, or unless Panel was refreshed/restarted, if I remember correctly.

There are other ways around this.  I know what I've done before with cacheing on webservers and images is you serve up a file called image.png?file_dt_tm.  Or with large javascript files, I've done the same.  That way when you change the file, your webserver will see it as different file, which forces downstream cacheing systems to re-request it.

[RoderickGI]

I'm seeing (disk cache) rather than (memory cache). See image.

[hoyt]

More investigation shows it is pulling from the disk cache sometimes.

In this case I filtered for a specific image so the console wasn't so junked up.

You can see it makes a huge difference.  Disk cache: 3ms, server request: >350 ms (for one image).  This should be improved to rely on the disk/memory cache unless the image has actually changed.  Panel should not be ignoring disk cache if I scroll up one row of items and back down within 2 seconds.

I believe this would make Panel far more responsive.

[RoderickGI]

Your times are quite long compared to mine, as shown in my image. I guess my server wasn't doing anything else, and it is probably caching the thumbnails file anyway. Certainly, the thumbnails file wasn't changing, so it would have been in memory and not being read from disk. Or should have been, if Windows was doing the right thing.

As these are thumbnails images and are stored in a thumbnails database and MC manages the serving of individual images, I'm not sure your image.png?file_dt_tm methodology would work. The individual thumbnails inside the thumbnails database may not have their own date and time stamps. A question for JRiver, rather than me!