View Full Version : Artwork resizing - could it be managed better?
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.
> 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
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
2008-10-23, 03:40
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.
> 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
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
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.
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
2008-10-23, 11:08
> 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
2008-10-23, 23:23
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)
> AH! No go for ReadyNAS and artwork "on demand" resampling then. But
> what does it do for 13 hours then?
As I said it lacks support for floating point operations in the CPU. Thus resizing one artwork might take 20 secs. vs. 2 secs in resize mode.
> It must be resampling and caching
> the resampled images somewhere. What size are they and where are they
> being cached to?
They're the size as used on the Controller (50, 56) plus what you've defined as the thumb artwork size in the web UI (100 by default).
> 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.
There's already an enhancement request for additional formats. You might want to add your voice.
http://bugs.slimdevices.com/show_bug.cgi?id=9757
> I also noticed that the web interface requests 100x100 and those also
> get resized and resampled on demand.
They should be pre-cached.
--
Michael
Fishbones
2008-10-24, 05:29
Thanks Michael...
I don't mind 13+ hours for a artwork scan as long as it's resampling, resizing and pre-caching so that when I need that image at 100x100 it does not have to do all that work again. And that's what it does apparently but I have searched the server and cannot find where the cached images are located.
Could someone please point out to me where the images are pre-cached on the server.
Cheers.
> Could someone please point out to me where the images are pre-cached on
> the server.
In the cache folder you'll find in Settings/Status.
--
Michael
Fishbones
2008-10-25, 07:03
Got it. (I was looking *.jpg files in cache :-|
I have been following bug9757 and it would be great if something like that could be done via the webUI. For now I'm going to try and apply the patch. erm ... after finding out to apply a patch to *.pm file that is...
Cheers
The Moog
2008-10-27, 05:08
Hi guys,
This might be a stupid question, and I apologise if it is, but could we not have the option of resizing/resampling album artwork offline on a proper PC? I have a ReadyNAS and a Controller, and it would be really nice to just let your (hopefully much more powerfull) PC perform all of the hard work, and dump the results into the ReadyNAS's cache file.
The Moog
Fishbones
2008-10-27, 07:27
Looking into the artwork cache directories I see that a scan generates and caches */*/cover_100x100_p images. When the webUI requests covers for the "Albums" menu squeezecenter generates and caches ANOTHER file */*/cover_100x100_o.
So we have */*/cover_100x100_p AND */*/cover_100x100_o in cache. Why doesn't the webUI use */*/cover_100x100_p that was generated by the scan?
> Looking into the artwork cache directories I see that a scan generates
> and caches */*/cover_100x100_p images. When the webUI requests covers
> for the "Albums" menu squeezecenter generates and caches ANOTHER file
> */*/cover_100x100_o.
Good catch! We originally used the _p covers in the web UI, but later switched to using _o. Alas, we forgot to adapt the pre-caching... This should be fixed in 7.3 r23698.
Thanks a lot!
--
Michael
Fishbones
2008-12-23, 06:13
[08-12-23 00:15:52.8045] Slim::Web::Graphics::processCoverArtRequest (618) caching result key: plugins/cache/icons/radioio_25x25_f.png, orig=
[08-12-23 00:15:53.1488] Slim::Web::Graphics::processCoverArtRequest (114) this is a transparent png request
[08-12-23 00:15:53.1648] Slim::Web::Graphics::processCoverArtRequest (197) cached image not usable because 'orig' undef
[08-12-23 00:15:53.1744] Slim::Web::Graphics::processCoverArtRequest (222) Asking for trackid: notCoverArt - radioproviders at size 25x25
[08-12-23 00:15:53.1813] Slim::Web::Graphics::processCoverArtRequest (316) got cover art image image/png of 26165 bytes
[08-12-23 00:15:53.5125] Slim::Web::Graphics::processCoverArtRequest (433) resizing from 336x336 to 25 x 25 using fitstretch
[08-12-23 00:15:53.5201] Slim::Web::Graphics::processCoverArtRequest (499) Set alpha for transparent png
[08-12-23 00:15:53.5274] Slim::Web::Graphics::processCoverArtRequest (521) Resampling file for better quality
[08-12-23 00:16:21.3728] Slim::Web::Graphics::processCoverArtRequest (567) outputting cover art image image/png of 1163 bytes
[08-12-23 00:16:21.4716] Slim::Web::Graphics::processCoverArtRequest (618) caching result key: plugins/cache/icons/radioproviders_25x25_f.png, orig=
[08-12-23 00:16:22.5571] Slim::Web::Graphics::processCoverArtRequest (114) this is a transparent png request
[08-12-23 00:16:22.5830] Slim::Web::Graphics::processCoverArtRequest (191) returning cached artwork image, image/png (729 byte)
Now with version 7.3.1, every time the webUI is loaded, most of the 25x25 icons are re-generated instead of being retrieved from pre-cached artwork. This causes the webUI to be very slow on each startup.
From the debug above you can see that this is due to:
"cached image not usable because 'orig' undef"
RabanePaco
2008-12-23, 16:32
I have many albums which don't show the cover.
It doesn't matter if I name the cover cover.jpg or folder.jpg and store it with the mp3's.
Many covers named XYZ123.jpg DO show, even if they aren't stored with the album.
I have one multi album CD. Album/CD1 does show the cover (named "Album name.jpg"), while Album/CD2 doesn't show it. The cover is with the CD2 album!
Etc.,etc.
I tried putting the cover in the tag, linking the cover to the tag, renaming (cover.jpg, folder.jpg), using MediaMonkey and Mp3Tag. [I don't know how I can see how the cover is stored in the mp3].
The covers do show in MediaMonkey and on my iPod.
Of course I rescan the DB after each change.
Someone who can enlighten me?
moley6knipe
2008-12-24, 06:58
Complete clear and rescan, yes? Tried clearing your web browser's cache?
RabanePaco
2008-12-24, 15:19
Solution:
Wiki: Album Artwork: (http://wiki.slimdevices.com/index.php/Album_Artwork) You must rescan with the "Clear and Rescan" option. One of the server settings.
bobkoure
2008-12-27, 11:58
The problem here is dev cost vs. use case.
It shouldn't be a lot of work to (for each track):
- for each cover-size needed:
-- look for an already-present jpg with a "magic name"
-- if there, use that rather than anything embedded or cover.jpg
This would let ReadyNAS folks run as script (probably on a different machine) to create the artwork in the needed sizes - and sidestep the whole no-floating-point issue.
Because this would just be something "optional", you could just let the ReadyNAS community come up with the script; the changes needed in the artwork scan seem fairly minimal, so, even though there isn't much of a use case (not lots of ReadyNAS users), there also wouldn't be lots of development needed.
Fishbones
2009-01-09, 00:43
Now with version 7.3.1, every time the webUI is loaded, most of the 25x25 icons are re-generated instead of being retrieved from pre-cached artwork. This causes the webUI to be very slow on each startup.
Quote:
[08-12-23 00:15:52.8045] Slim::Web::Graphics::processCoverArtRequest (618) caching result key: plugins/cache/icons/radioio_25x25_f.png, orig=
[08-12-23 00:15:53.1488] Slim::Web::Graphics::processCoverArtRequest (114) this is a transparent png request
[08-12-23 00:15:53.1648] Slim::Web::Graphics::processCoverArtRequest (197) cached image not usable because 'orig' undef
[08-12-23 00:15:53.1744] Slim::Web::Graphics::processCoverArtRequest (222) Asking for trackid: notCoverArt - radioproviders at size 25x25
[08-12-23 00:15:53.1813] Slim::Web::Graphics::processCoverArtRequest (316) got cover art image image/png of 26165 bytes
[08-12-23 00:15:53.5125] Slim::Web::Graphics::processCoverArtRequest (433) resizing from 336x336 to 25 x 25 using fitstretch
[08-12-23 00:15:53.5201] Slim::Web::Graphics::processCoverArtRequest (499) Set alpha for transparent png
[08-12-23 00:15:53.5274] Slim::Web::Graphics::processCoverArtRequest (521) Resampling file for better quality
[08-12-23 00:16:21.3728] Slim::Web::Graphics::processCoverArtRequest (567) outputting cover art image image/png of 1163 bytes
[08-12-23 00:16:21.4716] Slim::Web::Graphics::processCoverArtRequest (618) caching result key: plugins/cache/icons/radioproviders_25x25_f.png, orig=
[08-12-23 00:16:22.5571] Slim::Web::Graphics::processCoverArtRequest (114) this is a transparent png request
[08-12-23 00:16:22.5830] Slim::Web::Graphics::processCoverArtRequest (191) returning cached artwork image, image/png (729 byte)
From the debug above you can see that this is due to:
"cached image not usable because 'orig' undef"
Has any of the developers seen this ?
>> From the debug above you can see that this is due to:
> "cached image not usable because 'orig' undef"
>
> Has any of the developers seen this ?
Yes, I did see the thread. But I don't get those messages. What release
are you running?
Michael
Fishbones
2009-01-09, 07:10
>> From the debug above you can see that this is due to:
> "cached image not usable because 'orig' undef"
>
> Has any of the developers seen this ?
Yes, I did see the thread. But I don't get those messages. What release
are you running?
Michael
This happened with SqueezeCenter_7.3-sparc-readynas.bin and SqueezeCenter_7.3.1-sparc-readynas.bin.
I have since reverted to 7.2.1 so have not tested any of the betas.
Thank you.
> This happened with SqueezeCenter_7.3-sparc-readynas.bin and
> SqueezeCenter_7.3.1-sparc-readynas.bin.
I've tested again with the latest 7.3.2 code and it's using cached files. Seems good to me. Feel free to file a bug if you can still see this issue after updating to 7.3.2
--
Michael
Fishbones
2009-01-12, 06:56
Indeed! All OK now.
Cheers.
Powered by vBulletin® Version 4.1.12 Copyright © 2013 vBulletin Solutions, Inc. All rights reserved.