Bugzilla – Bug 3395
Names with non-filesystem safe characters cause problems with artwork
Last modified: 2007-10-16 09:39:40 UTC
If you use a centralized folder for artwork and use an InfoFormat to generate the file name, any expanded key that contains a non-filesystem safe character causes SlimServer to fail to find the artwork. For example, I have specified an artwork folder for my server, and have the Artwork name set to "%ARTIST - ALBUM". One of the albums I have ripped is The Velvet Underground's "White Light/White Heat". The problem is that the "/" is a path seperator and can not be used as part of a file name. Depending on the OS, other unsafe characters include ":" and "?" and "\". This problem exists in 6.2.2, 6.3 and 6.5. I'm volunteering to fix this, and have a patch I'm testing on 6.5 that replaces any unsafe character with a replacement string, specified as a preference. I'm also going to experiment with using the same code to try different ways of handling unicode characters in paths, so some of the problems with combining characters vs pre-combined characters can be solved. I'm a bit leary of the performance impact of that later though.
Robert - thoughts on this? Barry - having a pref doesn't seem like the best solution to me.
Hi Dan, I wasn't very clear in my original post, let me describe what I have working and what I plan to add before submitting a patch. Right now I have a hard coded list of characters that cause problems. When they are found, they are replaced with an underscore, so in the example I gave in the original submission the artwork file is "The Velvet Underground - White Light_White Heat". Everything works fine, both during a full scan and when browsing the music folder. (For backwards compatability my code only kicks in when an artwork folder has been set and the original search for an artwork file fails.) What needs to be done is to make the list of unsafe characters dependent on the operating system. Then I was thinking of adding the ability to set a preference to override the default list of unsafe characters, and to override the "_" with some other string. I wasn't thinking of exposing these preferences via the Server Settings section, but add the possibility of changing them by modifying the preferences file instead of the code. That way if I missed an illegal character, or a new file system comes out with different rules (admittedly unlikely) an update to the preferences is all that is needed, not an update to the code. As a longer term option, I want to extend the code to try replacing composed and combining unicode charactes with each other, so some of the annoyances caused by the file systems go away. (In other words, if my tags contain "a-acute" but my file system has the file containing an "a combining-acute" they will still match.) Make sense?
Some other thoughts that I would like to get your opinons on. It might be nice to extend the InfoFormat options to support things like partial strings, directory seperators, etc. I have a centralized artwork folder, and with over 500 albums the cover artwork and the thumbs result in over 1,000 files. I'd like to break those up into sub-directories. I could see specifying something like 'first letter of artist's name, path seperator, artist - album" so a final path would be something like "$arwork_folder/N/Nirvana - Nevermind.jpg". Maybe add some sort of ":#" suffix to an InfoPath tag that means take the initial n characters? -Barry
Can I suggest moving them to cover.jpg and thumb.jpg in each Album's directory? That would solve the problem, and is the prefered solution imo. Your artwork is then directly associated with the album. Using infoFormat for cover art is a bad, bad hack, and should be removed from the software.
cover.jpg would probably be preferred again over thumb.jpg. now that recent builds do the resizing on server side, the need for thumbnail based on thumb.jpg is a bit dubious.