PDA

View Full Version : The "no album art work image" isn't showing up, why?



st2000
2007-07-10, 07:38
Hi...

The "no album art work image" isn't showing up, why?

I have a number of albums w/art work that shows up on the web interface
and the target player. But, when there isn't art work in the directory
along with the music all I get is, well, no art work at all. I thought
I would get the:
/usr/local/slimserver/HTML/EN/html/images/cover.png
....art work (which, by the way, I can pull with the same web browser I
am using to control slimserver - so I don't think there is a permission
problem). Anyone know why?

....thanks.

st2000
2007-07-10, 18:46
stuart wrote:
> Hi...
>
> The "no album art work image" isn't showing up, why?
>
> I have a number of albums w/art work that shows up on the web interface
> and the target player. But, when there isn't art work in the directory
> along with the music all I get is, well, no art work at all. I thought
> I would get the:
> /usr/local/slimserver/HTML/EN/html/images/cover.png
> ...art work (which, by the way, I can pull with the same web browser I
> am using to control slimserver - so I don't think there is a permission
> problem). Anyone know why?
>
> ...thanks.
>

I think I figured this out (and sorry for posting what appears to be a
user question in the developer's list - however...)...

It turns out SlimServer is passing out PNG files with a JPEG name. I
assume the original intent was to pass back *something* if nothing was
available when a client requests album cover artwork using the name
"cover.jpg". However, this is confusing to any client which is basing
its decoding process on the file name extention. (By the way, asking for
"cover.png" returns an error - so SlimServer isn't even set up to pass
back this type of formatted image.)

So, can we change the default image to a real JPEG file?

....thanks

JJZolx
2007-07-10, 23:17
I think I figured this out (and sorry for posting what appears to be a
user question in the developer's list - however...)...

It turns out SlimServer is passing out PNG files with a JPEG name. I
assume the original intent was to pass back *something* if nothing was
available when a client requests album cover artwork using the name
"cover.jpg". However, this is confusing to any client which is basing
its decoding process on the file name extention. (By the way, asking for
"cover.png" returns an error - so SlimServer isn't even set up to pass
back this type of formatted image.)

So, can we change the default image to a real JPEG file?

What I've seen is that SlimServer will serve two different versions of cover.png for missing thumbnails, depending on the circumstances.

When an album has no artwork it serves cover.png, without resizing it using the GD library. This image is seen as a light gray question mark on a medium gray folder (I think that's what it is) on a transparent background. It's name will be 'cover.png'.

The second image that is sometimes served may not be intentional. When something screws up the caching of thumbnails, then the image is cover.png, except this time it _is_ resized by GD. This is the image you're seeing with the .jpg extension. It won't be named 'cover.png' - instead it will have the filename of the thumbnail that should have been in the cache. This is the same image as above, except that it appears on a black background - apparently GD can't maintain the transparency, or maybe it's not be being called correctly, or maybe it's the file type confusion.

Yes, I think there's definitely a bug in there somewhere. Maybe the thumbnailing/caching code should never resize cover.png, or maybe it shouldn't resize it and serve it using the wrong file type.

I've seen instances in the past on my server where every single thumbnail served is the second, resized image with the black background. Once that happens the only way to fix it is to run a full wipe/rescan.

If the artwork for an album really is missing then you should be seeing the first image, not the second.