PDA

View Full Version : Would support for "Folder.jpg" (uppercase F) be useful?



SadGamerGeek
2007-01-09, 03:37
I'd been wondering why lots of my cover art wasn't displaying in the Slimserver web front-end. After some investigation I realised that the problem albums had a cover-art picture named Folder.jpg. This must be because quite a lot of my cover-art is added manually by me (Google image search, then save). Windows thinking it knows best, tends to capitalise the first letter of a filename, so even though I type folder.jpg, it saves a file called Folder.jpg. Now I've realised what's going on, it isn't a massive problem for me to write a little script to fix these files. It might be quite useful though, if the scanner actually treated these exactly the same as the lower-case variant.

What's the general thoughts on this? If I hear any positive noises I'll raise it as a request.

slimpy
2007-01-09, 04:48
Simply add Folder.jpg to the list of file names under Server settings - Interface - Artwork

-s.

SadGamerGeek
2007-01-09, 04:54
Doh!

Thanks for that!

I'll attempt to RTFM next time......

hunta
2007-01-09, 08:09
I'll attempt to RTFM next time......

Does such a thing exist? My apologies if it does, and I know this has come up before, but I've searched for an easy-to-follow 'How To' on album art but not found anything that really fits the bill. Maybe I should be adding this into the threads about usability...

Anyway, my collection is all ripped from CD as high quality mp3's. I then use MediaMonkey to ensure the tag includes album art. Does this tag have the image embedded in it, rather than being stored as a linked file? If so, is there anyway I can get it out and store it so that SS can use it too? Or perhaps SS can be configured to use the images embedded in tags?

Maybe someone could give a step-by-step breakdown of how they add new albums including artwork into their library. Honestly, I've tried, but always ended up defeated and frustrated! I'd be happy to RTFM if someone could point me in the right direction!

Andrew

slimpy
2007-01-09, 08:53
Slimserver finds cover art in one of the following ways:
-from id3 tags, APIC frame
-from flac/vorbis comments, COVERART=(image base64 encoded)
-a picture file located in the same folder, by default, images named "cover.jpg", "albumartsmall.jpg", "folder.jpg", "album.jpg" or "thumb.jpg" are used or you can specify your own name in server settings - interface - artwork.

-s.

The latest development versions of slimserver (7.0) also read the new flac image block.

peter
2007-01-09, 09:16
slimpy wrote:
> Slimserver finds cover art in one of the following ways:
> -from id3 tags, APIC frame
> -from flac/vorbis comments, COVERART=(image base64 encoded)
> -a picture file located in the same folder, by default, images named
> "cover.jpg", "albumartsmall.jpg", "folder.jpg", "album.jpg" or
> "thumb.jpg" are used or you can specify your own name in server
> settings - interface - artwork.
>
That's all wonderful, but if the software is running on a
non-case-sensitive OS it should ignore case while matching filenames.
I've been using Unix for 15 years and I still consider case sensitive
filenames a misfeature. No need to repeat that on a consumer device.

Regards,
Peter

kdf
2007-01-09, 09:48
On 9-Jan-07, at 7:09 AM, hunta wrote:

>
> SadGamerGeek;168520 Wrote:
>> I'll attempt to RTFM next time......
>
> Does such a thing exist?

http://wiki.slimdevices.com/index.cgi?AlbumArtwork
http://wiki.slimdevices.com/index.cgi?ToolsAlbumArt

simple thing: use Tag & Rename to grab album info from Amazon, and have
it store the art in tags and as a file. It just works.

Or forgoing any tool advocacy, just store a cover.jpg file in the same
folder as the tracks for the album and put each album in a folder.

-kdf

MrSinatra
2007-01-09, 13:28
i have posted on the forums how i use WMP to get folder art as i rip. pretty easy and painless.

also, since XP and WMP capitalize the F, why not simply include BOTH:

folder.jpg

and

Folder.jpg

in the SS code? meaning, have it look for both separately? seems silly not to, knowing that xp and wmp default to this.

hunta
2007-01-10, 06:50
On 9-Jan-07, at 7:09 AM, hunta wrote:

>
> SadGamerGeek;168520 Wrote:
>> I'll attempt to RTFM next time......
>
> Does such a thing exist?

http://wiki.slimdevices.com/index.cgi?AlbumArtwork
http://wiki.slimdevices.com/index.cgi?ToolsAlbumArt

simple thing: use Tag & Rename to grab album info from Amazon, and have
it store the art in tags and as a file. It just works.

Or forgoing any tool advocacy, just store a cover.jpg file in the same
folder as the tracks for the album and put each album in a folder.

-kdf

kdf, thanks again for your help.

After a certain amount of head-scratching, I am well on the way to getting my library straightened out. There are a few additional points worth mentioning as I was having problems with albums appearing multiple times:

- I had a number of albums with blank (i.e. white, rather than no) artwork, even though there were valid cover art files in the folder. This was due to a 1x1 white pixel in the tag, which seem to correspond to around the time I used iTunes for ripping. The SS browser interface would show this as blank artwork (white, not the '?' icon) in the album list, but would show the correct image when viewing a single album's details. Attaching the file to the tag in Tag&Rename solved this one.
- It's definitely worth removing tags and recreating them, as opposed to updating them. This from another thread I saw about how multi-format tags can be read multiple times, resulting in duplicates. Tag&Rename has this function.
- Another source of duplicates was the MusicIP cache. Tracks need to be rescanned and any updated tags (=new tracks) validated. SS seems to hang on to the track in the MusicIP cache as mixable with the new version also showing as unmixable until this is done.
- Periodic full library deletions and rebuilds don't go amiss either.

Thanks to those who contributed pointers for this.

Andrew

kdf
2007-01-10, 09:32
On 10-Jan-07, at 5:50 AM, hunta wrote:
>
> - Another source of duplicates was the MusicIP cache. Tracks need to be
> rescanned and any updated tags (=new tracks) validated. SS seems to
> hang
> on to the track in the MusicIP cache as mixable with the new version
> also showing as unmixable until this is done.

This is an excellent note, and one that I'm certain gets overlooked so
many times. MusicIP doesn't have the same abilities on all platforms.
I believe on windows there is supposed to be some live folders, but in
most cases you DO need to do a reload to update for changes.

-kdf