Artwork resizing - could it be managed better?

[cwinson]

Bit of a long one this I'm afraid....

I've been doing some investigation into artwork resizing and caching in 7.01, prompted by the fact that it takes 30 secs to resample a 500x500 image on my RadyNAS NV+ to each required size, which means teh interface runs like a dog

Note: I have tried reducing the size of my standard artwork files to see if it helps - it does reduce the resample time (to 15 secs), but it's still not manageable


Having turned on logging in the server, I've seen the following:

1) Artwork is cached on a per song basis, rather than a per-album basis

2) The initial scan creates and caches some artwork sizes (see below) but only for the first song in the album

3) There are 7 different representations of artwork that I've seen:

50x50 (pad) - Created and cached for each album during initial scan. Used for web interface album thumbnails

100x100 (pad) - Created and cached for each album during initial scan. Used for web interface 'now playing' thumbnails

56x56 (original) - Created and cached for each album during initial scan. Used in controller interface for album thumbnail

96x96 (pad) - Not created during initial scan. Used for 'now playing' thumbnail in web interface. Gets created and cached when a song is first played via controller, causing delay in now playing artwork to appear

154x154 (original) - Not created during initial scan. Used for smaller 'now playing' thumbnail in controller. Gets created and cached when a song is first played via controller, causing delay in now playing artwork to appear

186x186 (original) - Not created during initial scan. Used for larger 'now playing' thumbnail in controller. Gets created and cached when a song is first played via controller, causing delay in now playing artwork to appear

240x240 (original) - Not created during initial scan. Used for 'show artwork' screen in controller. Gets created and cached on first request, causing delay in artwork to appear

25x25 - Not created during initial scan. Used for small non-artwork thumbnails in the web interface. Gets created and cached on first request, causing delay in the web interface to work first time


3) Most of the standard icons which sit alongside the cover art (e.g. 'no cover art' logo, favourites logo, genre logo etc.) come in a standard jpg size (336x336) and have to be resampled on first use in the interfaces (web and/or controller). This causes delays in first use of either interface - particularly when using readyNas server



Some observations:

1) The initial scan doesn't do much to help the controller interface in terms of resizing and caching artwork. Only the 56x56 image is used by the controller

2) There is no sharing of cached cover art for different songs in the same album. I understand that some people may have embedded artwork which can vary by song, but if folder.jpg is used, the cached versions should be re-used where possible

3) More could/should be done during the initial scan to help out those of us who predominantly use the controller interface as opposed to the web interface. Perhaps this could be made configurable so that I could get all resizing and caching requirements done up front as opposed to on first use.

4) If nothing can be done around point 2 (different songs, same album), getting the initial scan to create artwork for all of the songs would be useful - at least as an option

5) The standard logos used in the interfaces should be pre-prepared and cached to meet requirements rather than on first use.


Overall, I think there a lots of things that can be done around the management of artwork which would make the interfaces run much better. It's particularly bad with ReadyNas, but would help across the board. It may take some more programming and/or config options, but I think it's worthwhile.

If all I had was my readynas nv+ to run the server, I would have given up on the duet and returned it. At the moment, I'm using another machine to run the server and it's useable - but has other issues. Ideally I would migrate back to readynas as it's the only always-on machine in the house.

[mherger]

> 1) The initial scan doesn't do much to help the controller interface in
> terms of resizing and caching artwork. Only the 56x56 image is used by
> the controller

Nope. Now Playing and screensaver use the other sizes.

> 2) There is no sharing of cached cover art for different songs in the
> same album.

This issue is being tracked in a bug report (don't remember its number)

> 3) More could/should be done during the initial scan to help out those

Please define "more"?

> Overall, I think there a lots of things that can be done around the
> management of artwork which would make the interfaces run much better.

The problem here is dev cost vs. use case. ReadyNAS is by far the slowest device out there regarding this issue. ReadyNAS users are a small bunch. And most of them seem to be happy with the current compromise.

> It's particularly bad with ReadyNas, but would help across the board.

That's especially true for 2. which we're addressing.

--

Michael

[cwinson]

Thanks for the responses Michael.

To answer the question around what I mean by 'more could/should be done during the initial scan', I would propose the following:

1) Provide a set of options which configures the resampling and caching of the various artwork sizes during the initial scan. Knowing my RadyNAS struggles with the resizing, I would pre-scan the 56x56, 154x154, 186x186 and 240x240 images which are used by the controller - plus possbily the web ones as well so I can access the settings page within a reasonable timescale. The initial scan would take a long time, but this could be scheduled overnight

2) Resize and cache the standard icons (e.g. no album cover, favourites etc.) during the initial scan. At the moment, I'm not sure if they're even cached on first use.

3) Run the logic to determine artwork location for each track (embedded tag vs. folder.jpg etc.) during the initial scan. This would also fix the issue reported by EliteAV in the following thread where this per-track check causes delays in browsing albums.

http://forums.slimdevices.com/showthread.php?t=45121


Add to this the ability to share cached artwork across tracks so the resizing doesnt have to occur multiple times (as per the bug you mention) and I think the overall responsiveness of the controller would be far better. For me, it would make the readynas solution workable without having to use the degraded artwork option.

Chris

[Fishbones]

I'm running SqueezeCenter 7.2.1 on a ReadyNAS Duo and have noticed that when a scan is done with "Resample Artwork" set in the performance settings, viewing album art in the web interface and consequently also on a Philips Pronto with the SlimPronto module, is very slow to non functional.
When a scan is done with "Resize Artwork", cover art loads in seconds.

A scan with "Resample Artwork" set takes +-13 hours.
A scan with "Resize Artwork" set takes +-1 hours.


So what is happening here? Does album art, either resampled or resized, get cached on the server? If it's not cached, why does it take 13 hours to resample artwork?

TIA.

[mherger]

> When a scan is done with "Resize Artwork", cover art loads in seconds.

There's one reason that option exists at all: ReadyNAS. We only introduced it because the ReadyNAS isn't able to resample the artwork in a reasonable amount of time.

> why does it take 13 hours to resample artwork?

AFAIK because the ReadyNAS doesn't have a floating point unit.

--

Michael

[cwinson]

Been a while since I looked at this. In truth, this issue turned into a showstopper for me and I've ended up using itunes and the iphone/ipod remnote app instead. As I'm using softsqueeze, this works fine for me.

From memory, the problem you are having is that the ReadyNas CPU is particularly poor at running the resampling code

This is compounded by the fact that the initial scan only creates caches for some of the artwork sizes used in the controller and the web interface - the rest has to happen on the fly, which kill the user experience.

Don't know whether any of my suggestions above were taken into account in later releases, but to be honest, I don't really care at this stage. The slim duo is packed up along with other redundant kit. I would peddle it in ebay if it wasn't for the fact that it's got scratches all over the back from where the controller was actually taken out of the cradle.

Nice idea - bad implementation

[peter]

cwinson wrote:
> Been a while since I looked at this. In truth, this issue turned into a
> showstopper for me and I've ended up using itunes and the iphone/ipod
> remnote app instead. As I'm using softsqueeze, this works fine for me.
>
> >From memory, the problem you are having is that the ReadyNas CPU is
> particularly poor at running the resampling code
>
> This is compounded by the fact that the initial scan only creates
> caches for some of the artwork sizes used in the controller and the web
> interface - the rest has to happen on the fly, which kill the user
> experience.
>
> Don't know whether any of my suggestions above were taken into account
> in later releases, but to be honest, I don't really care at this stage.
> The slim duo is packed up along with other redundant kit. I would peddle
> it in ebay if it wasn't for the fact that it's got scratches all over
> the back from where the controller was actually taken out of the
> cradle.
>
> Nice idea - bad implementation
>

Using a NAS for a media server is a bad idea indeed.

X.

[cwinson]

I'm not sure that's the case - most of the NAS boxes out there are stripped down Linux boxes which should be perfectly capable of running a media server. Of course it depends on what the media server is trying to do.

The issue for me around this whole episode was that ReadyNAS was purported to be capable of running the software. It wasn't immediately apparent that this came with big caveats. The option to run with resized artwork was not workable for me - the artwork looked awful.

I should note that I also ran for a period of time with the software running on a full PC. I still found the performance and responsiveness of the controller disappointing - I guess I have high expectations...

Of course, that was when it was able to get a wireless signal..

[Fishbones]

> When a scan is done with "Resize Artwork", cover art loads in seconds.

There's one reason that option exists at all: ReadyNAS. We only introduced it because the ReadyNAS isn't able to resample the artwork in a reasonable amount of time.

> why does it take 13 hours to resample artwork?

AFAIK because the ReadyNAS doesn't have a floating point unit.

--

Michael

AH! No go for ReadyNAS and artwork "on demand" resampling then. But what does it do for 13 hours then? It must be resampling and caching the resampled images somewhere. What size are they and where are they being cached to?

I turned on debug for artwork and noticed that SlimPronto requests 64x64 images to display a coverart collage. Squeezecenter then resizes from the original folder.fpg of 500x500 to 64x64. Now if these 64x64 images were already cached then there would be no need for this on demand resize. Images would just be retrieved from cache. So we could have resampling enabled and the only downside would be the long scan time.

I also noticed that the web interface requests 100x100 and those also get resized and resampled on demand.

[MrSinatra]

i think a user, and esp a nas user, should be able to optionally run scans with settings they choose.

imagine an "artwork only" scan. imagine a "music only" scan.

sure, this may mean your music and art are somewhat out of sync at times, but the user should have the option.

(other options in a scanner would be what to look for, so you could turn off looking for embedded artwork, or certain tags you don't need or care about, and as i've mentioned elsewhere, the ability to turn off automated logics like VA and GH)