where in trhe docs is Cover.jpg mentioned?  This shouldn't be documented, as it is all lower case that is looked for.  folder.jpg is searched, and I use that on my system where certain tools have created it.  Folder.jpg will not work. 

Finally, please do not preset targets.  these are set only after internal reviews.

In Windows the directory operations will all be case-insensitive, so it must be in the server's string comparisons that 'Folder.jpg' is not considered the same as 'folder.jpg'.  So why not make these comparisons case-insenstive?

(In reply to comment #2)
> So why not make these comparisons case-insenstive?

Now that I think about it, this may be a really bad idea. :-)  If someone were to moves their server from a Windows machine to a Linux server or NAS they may wonder why their Folder.jpg files are no longer recognized.  Better to document exactly the file names that will be recognized and note that the names are case sensitive on all platforms.

(In reply to comment #3)
> (In reply to comment #2)
> > So why not make these comparisons case-insenstive?
> Now that I think about it, this may be a really bad idea. :-)  If someone were
> to moves their server from a Windows machine to a Linux server or NAS they may
> wonder why their Folder.jpg files are no longer recognized.  Better to document
> exactly the file names that will be recognized and note that the names are case
> sensitive on all platforms.

I would expect this to generate significant numbers of support queries - especially as Windows software such as media player will capitalise the first letter of the filename by default.  If you're running a server on a case sensitive box but using Windows clients (surely quite a common occurrance) the resulting default behaviour won't work.  And Windows doesn't make it easy to change just the case of a filename.

What's wrong with just searching for jpg files using both cases that are likely to exist?

(In reply to comment #4)
> What's wrong with just searching for jpg files using both cases that are likely
> to exist?

'Both' cases?  A lot of sofware also creates file extensions in all caps.  That alone leads to four variations of each:

folder.jpg
folder.JPG
Folder.jpg
Folder.JPG

And if you advertise case insensitivity, then fOlder.jpg and fOLDER.JPG and FOLDER.jpg and ... should all qualify as valid.

(In reply to comment #5)
> 'Both' cases?  A lot of sofware also creates file extensions in all caps.  That
> alone leads to four variations of each:
> And if you advertise case insensitivity, then fOlder.jpg and fOLDER.JPG and
> FOLDER.jpg and ... should all qualify as valid.

I was trying to give Jim another option as in his second comment he seemed not to like the idea of making the search for Album Art files fully case insensitive.

Why document a limitation and cause confusion where the limitation could just be removed?

FWIW, in Artwork.pm we currently look for prefixes:

cover Cover thumb Thumb album Album folder Folder

and suffixes:

png jpg jpeg gif

So, the examples you gave _should_ work in 7.0.

That said, I agree, the cover art file names should be completely case insensitive (especially considering that for the two most popular platforms, the other file system operations are.)

It's a little bit of a tricky change because it explodes the number of files that need to be tried to opened.   The code would need to be changed to iterate through the files in the dir looking for a match with a constructed regexp.

Will review post 7.0.

i use:

Folder.jpg

as its the larger of the two artwork sizes that WMP puts in a dir.  (i rip with EAC, but have WMP open monitoring the rip dir to get the art)

i set SS to use Folder.jpg to make the thumbs in browse artwork.

and, my rips are organized as ..\artist\album\songs.mp3 in almost all cases, with some being in dir cats while others are off the root.  my downloaded stuff however, is all in big dirs, with lots of mp3s, organized loosely by genre.

in any case, what i proposed on the forums long ago, is if after SS's "guesses" as to what the filename is haven't worked, and if after user directives haven't worked, why not have it just use any case (upper or lower or mixed) of any image suffix that happens to be in the dir?

for instance, *.jpg

this would beuseful for my downloaded stuff as well, as i could have "genre" artwork, and just throw an image in there, and not worry about what its called.  (i know its a small thing to rename whatever to Folder.jog, but why not make SS smarter?)

and i think doing this, just having SS recognize any art file in a folder after going thru its narrow structured search, would solve some of these other related problems people are having with when they change or update their art, etc...  it also keeps them from having to learn all these conventions, it would just work.  (granted, i mean the end user exp, i don't know how hard this is to implement)

*** Bug 8128 has been marked as a duplicate of this bug. ***

where is the new_schema keyword?

i also want to mention again that after the structured search, using ANY available artwork file seems to be a good idea to me.

Moving 7.4 bugs to 8.0.