Bugzilla – Bug 16620
SBS 7.6, new artwork resizing, "F" option doesn't seem to work
Last modified: 2011-05-12 10:16:00 UTC
I use "/music/...../cover_768x768_F_000000" to download the big artwork for the NowPlaying screen in iPeng for iPad (and similar commands in other iPeng versions). "F" is supposed to mean that I get a _downscaled_ version of a cover if the original file had a higher resolution than requested and the original size whenever the file had a lower resolution. In current SBS 7.6 builds this will always return an image sized 768x768 (minus cropping) even if the original file was smaller.
Hmm, some of those options were removed when I switched from GD to Image::Scale. Wasn't aware anyone used this one.
The problem is "F" is the one that clearly makes most sense for higher resolutions. iPad and iPhone can scale pretty well themselves and there is little sense to send an upscaled 768x768 (or even worse, the 960x960 used on iPhone 4!) image over the network if it's really just 128x128.
Andy - this is a real issue: the new artwork handler is upscaling all artwork if requested larger than original. This is definitely killing usability on eg. a ReadyNAS which can see the CPU pegged for 30-50s when requesting such a file. I'd expect this to be an issue for fab4 too. I wouldnt't be surprised if some of the "playback cuts out at the beginning of the track" reports were related to this.
== Auto-comment from SVN commit #32345 to the slim repo by fmueller == == http://svn.slimdevices.com/slim?view=revision&revision=32345 == Bug: 16620 Description: Add 'F' option to GDResizer - return original if requested size is bigger, return downsized if requested size is smaller
Can this be closed or the severity changed?
Joerg, can you confirm the fix?
Looks OK for what I can see here. Tested 7.6 trunk.
Closing per Joerg's comments.