View Full Version : ReadyNAS cover art resampling

2008-06-06, 12:51
I've been looking at getting squeezecenter 7.x running on my ReadyNAS NV+ to feed a new duet setup.

Initial attempts were disappointing due to cover art scaling, so I altered the performance options to resample the artwork as opposed to scaling only.

Artwork now looks fine, but it takes an absolute age to resample each file. The logs are showing the resampling taking 30-40 seconds for each file:

[08-06-06 19:41:41.8060] Slim::Schema::Track::coverArt (271) Retrieving artwork for: file:///MUSIC/FLAC/All%20Saints/All%20Saints/01%20-%20Never%20Ever.flac
[08-06-06 19:41:41.8360] Slim::Schema::Track::coverArt (287) Found cached file: /MUSIC/FLAC/All Saints/All Saints/folder.jpg
[08-06-06 19:41:41.8511] Slim::Web::Graphics::processCoverArtRequest (221) The variable $actualContentType, which attempts to understand what image type the original file is, is set to image/jpeg
[08-06-06 19:41:41.8584] Slim::Web::Graphics::processCoverArtRequest (247) got cover art image image/jpeg of 57040 bytes
[08-06-06 19:41:42.1032] Slim::Web::Graphics::processCoverArtRequest (366) resizing from 500x500 to 100 x 100 using pad
[08-06-06 19:41:42.1124] Slim::Web::Graphics::processCoverArtRequest (438) This is a gif with transparency
[08-06-06 19:41:42.1236] Slim::Web::Graphics::processCoverArtRequest (454) Resampling file for better quality
[08-06-06 19:42:20.0966] Slim::Web::Graphics::processCoverArtRequest (500) outputting cover art image image/gif of 7744 bytes
[08-06-06 19:42:20.1078] Slim::Web::Graphics::processCoverArtRequest (544) caching result key: 120-pad-100-100-0-.gif, orig=/MUSIC/FLAC/All Saints/All Saints/folder.jpg
[08-06-06 19:42:20.2384] Slim::Web::Graphics::processCoverArtRequest (106) this is a transparent gif request
[08-06-06 19:42:20.2454] Slim::Web::Graphics::processCoverArtRequest (160) artwork cache key: 133-pad-100-100-0-.gif
[08-06-06 19:42:20.3303] Slim::Web::Graphics::processCoverArtRequest (211) Asking for trackid: 133 - cover at size 100x100

My stock artwork format is 500x500 jpg.

Can anything be done to tune this?

2008-06-06, 12:56
You've probably already considered this, but in case you haven't: why not replace the artwork with artwork sized to what you want to display on SC, which appears to be 100x100? You should be able to crank through the re-sizing in batch or semi-batch mode using one of several different graphics packages.

2008-06-06, 13:33
Have thought of that but not tested. There are a few different thumbnail formats required for the duet, so some resampling will always be required. If resampling time is directly related to pixel count then resampling to 25x25 (small thumbnail) would take 25x longer with 500x500 than 100x100, so worth a try.

Ultimately, it took me a long while to get good quality cover art for my collection. Squeezebox isn't the only front-end - I also use a media center, so don;t want to throw it all away.

Would have though that even the processor in the ReadyNas could cope with this - it's not rocket science after all.

What perl modules are being used? Can they be replaced?

2008-06-06, 13:59
I don't know the answer to your perl module questions, but definitely don't throw away your work on the 500x500. You could possibly keep your 500x500 folder.jpg files for your media center, save the resized 100x100 files as cover.jpg (or something else) and tell SC to use those instead of folder.jpg. As for the ReadyNAS coping with it, you're right that it's not rocket science, but the hardware in the ReadyNAS was spec'd for serving files, not running audio servers or manipulating graphics output.

Try it on a few files and see if the result is more liveable than what you have now.

2008-06-06, 14:12
Resizing is done using libgd so I don't know how much faster it can get. Part of the problem is the lack of floating point on the ReadyNAS CPU. Of course, we'd welcome any help in speeding up artwork resizing on any platform. :)

2008-06-08, 19:40
> Artwork now looks fine, but it takes an absolute age to resample each
> file. The logs are showing the resampling taking 30-40 seconds for each
> file:

Now you know the one and only reason we added the resize/resample option...