Fix up Squeezeplay Playlist icon generation

[mw9]

Within the last few years I have been noticing that Squeeze's Clear Playlist and Save Playlist icons are not always being generated.

I regularly see this:

But I should be seeing this:

I now realize that this arises because I switched from using the 'Default' skin to the 'Material' skin. The source images, from which the icons are generated, are located in the 'Default' skin hierarchy, and are not found when using 'Material'. They need to be in the generic fallback 'EN' hierarchy if they are to be found independently of the current skin in use.

This proposed change fixes the issue by moving the relevant source images into the 'EN' hierarchy.

It also removes a couple of other redundant images from the 'Default' hierarchy. These are binary duplicates of images already present in the 'EN' hierarchy, and serve no purpose. (Images are cover.png and radio.png).

Remark:

Not all of the playlist related images are actively in use. Only playlistclear.png and playlistsave.png are actively referenced. But it makes sense to move all other related artwork. ( blank.png was historically used as the 'save' and 'clear' icon in early versions of Squeezeplay).

This is a list of the playlist related images that will be moved:

blank.png
playlist.png
playlistadd.png
playlistclear.png
playlistclear_40x40_m.png
playlistedit.png
playlistsave.png
playlistsave_40x40_m.png

[michaelherger]

Good catch! Thanks!

[mw9]

It makes me wonder if the graphics resizer should really be searching through skins for a url in the plain /html hierarchy. I haven’t worked that through. I don’t think it would if the url were in the /music hierarchy.

It happens here:

slimserver/Slim/Web/Graphics.pm

Line 369 in 4fd1b56

if ( $fullpath !~ m{^/|^https?} && $fullpath !~ /^[a-z]:[\\\/]/i && $fullpath !~ /^\\\\/i ) {

[michaelherger]

Most of the icons are 512x512 - therefore we need to resize them for eg. the Radio. And as skins should be able to overwrite some with their own we have to do that all the time. Does that make sense?

[mw9]

Oh yes, that makes perfect sense. I guess we have to see the html/image hierarchy as serving two possible demands, (a) that of a specific skin, which might like to define its own icons (e.g. material), and (b) Squeezeplay players, whose icons should always be unaffected by the skin currently in use.

I think I noticed a difference in approach here as compared with processHTTP. In that case something in the /html hierarchy is “not a skin”.

slimserver/Slim/Web/HTTP.pm

Line 656 in 566fbf4

if ( !main::WEBUI || $path =~ m{^(?:html|music|contributor|plugins|apps|settings|firmware|clixmlbrowser|index\.html|imageproxy)/}i || Slim::Web::Pages->isRawDownload($path) ) {

But, as said, I haven’t worked through, and, with certainty, I only have a very sketchy picture.

Clearly the current EN fallback scenario works, and has done for years. I think I was initially confused/puzzled by this apparent difference in approach.