Bugzilla – Bug 5873
No resize of cover art in squeezecenter's right panel
Last modified: 2007-10-24 11:03:00 UTC
Having a cover art file placed into every directory using format /<Artist>/<Album>/cover.bmp (all in BMP format) some times the image isn't resized correctly. Please see screenshot at http://www.punga.de/images/slim_bug1.jpg This only happens with some covers. If creating a mixed song list most of the cover arts are shown correctly, some others are huge-sized and seems not to be resized. An Example of an non-resized cover art can be found at http://www.punga.de/images/cover.bmp For some cover arts, the image link is broken although the file exists within the directory. Please see screenshot http://www.punga.de/images/slim_bug2.jpg - you can find the broken image at http://www.punga.de/images/cover_broken.bmp
I don't believe that server resizing actually supports bmp format. It's for gif, png and jpg. I'd be interested in where you saw it documented that cover.bmp was a supported artwork option. That should be changed.
You're right, although the document at http://wiki.slimdevices.com/index.cgi?AlbumArtwork says "SlimServer will display any graphic file that your browser can support. Nearly all browsers support GIF and JPG files, so most SlimDevices customers use one of these file formats." it ends with "NOTE: At this time, the server resizing only supports JPG, PNG or GIF image formats" Interesting enough, that the resize works for most bmp-covers, although they are in different (bigger) dimensions. Image properties from SqueezeCenter's html-pages show, that cover.bmp is converted and referenced as png. Maybe the note is valid only for version 6.5 and not modified already to fetch the featureset of version 7 ?! PS: I need to use bmp images because I run rockbox on my iPod and that is supporting bmp images only.
I use rockbox as well, but I have folder.jpg and convert those to cover.bmp to work with rockbox. I use a linux script provided on the rockbox wiki. There are windows tools listes there as well. If resizing is working, then see if you can find what is different between working and not working as far as any bmp subformat. Double check that all are working in rockbox as well. It's not unheard of to find filenames as bmp that are really gif format, and gif files that aren't gif format.
Hi KDF, sure, there are many ways to create a duplicate artwork in jpg or gif format. Also it's not my idea to force this feature, but since BMP is checked within /slimserver/server/Slim/Music/Artwork.pm->sub _imageContentType() I believe the developers idea is to support BMP - and this is why I created this bug report :) All bmp files are created from scratch using the same application (converting based on images coming from the same source). Since no other application has problems reading/showing the (tested) images, I think there may be a bug within the resize routine of SlimServer...
That line is there because BMP image content was showing up in files that were marked as .gif, so SC needed to find and flag the right content types in order to avoid making the problem worse by trying to deal with image data it thinks if of a different type. The important code for artwork support is the following two lines from _readCoverArtFiles: my @names = qw(cover thumb album folder); my @ext = qw(png jpg jpeg gif); SC is using the GD library to manipulate images to fit, so we depend on it's support. So far, this does not include bmp, so what should be done is perhaps more in the way of flagging and blocking any broken attempts to handle bmp once detected. I've cc'd Ben as he's been working with the GD library lately and may know if the recently updated version can deal with bmp effectively. Just because something is mentioned in code, does not always imply support. I simply means there are things that DO have to be handled in a reasonable way, even if it's to properly not support it. If GD still doesn't support bmp, then we should change the settings for custom artwork filename so that a bmp filename is not valid.
GD does not support BMP. I vote to strike it from valid formats.
Thanks for the clarification. Too bad that support for bmp seems to be kicked, but as you already said: It's a ease to create a duplicate for the bmp image using a supported image format, so it shouldn't be a big deal. Cheers Punga
Created attachment 2311 [details] validate coverArt pref for valid suffix to match supported filenames. adds a setValidate for coverArt pref to only allow entries with no suffix, or a suffix that matches the supported types.
Andy do you make the ruling on whether or not KDF should commit his change?
Fine with me, bmp sucks. :)
added a validation on accepted types for coverart setting, to help avoid problems like this in future. in effect at change 14069 as this was the basic issue, I'll mark as fixed. However, it can be reopened (preferrably retitled) if there is more to deal with.