Are the music files stored on a local disk or a NAS? NTFS or FAT32?

Hmm... as with the probably related bug 7815 this does work for me (see https://bugs-archive.lyrion.org/attachment.cgi?id=3229) using rev. 18805. 

- the songs do play, but you don't see the artwork?
- are you using importers like iTunes or MusicIP? 
- what file format is your music stored in?
- Are you using cue sheets or something?
- what are the exact server details as found on Settings->Status?

The problem remains in build 18806.

All songs show up and play correctly. It's only the artwork that does not show for albums in folders with foreign characters in the folder path name.

All files are in FLAC. Artwork is stored in "artwork.jpg", 700x700 pixel color JPEG (JFIF 1.02 compliant). 

No importers are used (as far as I know)
No cue sheets are used (as far as I know)

When rescanning the music library and watching the "Status" page, I noticed that none of the albums/artists with foreign characters ever showed up under "Artwork Scan". Apparently the Artwork Scan is choking on the non-US characters and not scanning those folders at all.

I am using Windows Vista x64 (Ultimate). Maybe this is a Windows Vista specific issue?

Thanks,
Peter

BTW, let me point out that the problem seems to apply to any characters outside the 7-bit US-ASCII range, for instance this artwork cannot be found either:

"E:\Music\Kotiteollisuus\±0\artwork.jpg"

Thanks,
Peter

Still can't reproduce this issue :-(.

Could you please narrow down your music folder to one folder with some subfolder having non-latin characters. Then set logging for scan.* and artwork to debug, run a full wipe/rescan and upload the scanner.log to this bug.

artwork.jpg isn't a supported file name. You said this had worked before?

From Slim::Music::Artwork:
	my @names      = qw(cover Cover thumb Thumb album Album folder Folder);

But even when adding artwork.jpg to the user defined file names this does work for me, whether it's "Ärzte" or not.

BTW: I've tested this on XP as well as on Vista.

Yes, I've added artwork.jpg as a user defined file name.

This worked fine in 7.0GA, and in older nightly builds (when installed on top of 7.0GA).

Because of a problem with the SBC, I recently did a complete uninstall. I then installed the latest nightly build. This is when I ran into this problem for the first time.

Could the problem be that I first need to install 7.0GA, and then apply the nightly build on top of that?

Thanks,
Peter

Let me emphasize that the problem I see is completely consistent: 

If the directory path name is plain 7-bit US ASCII, the artwork is ALWAYS found (artwork.jpg). 

If the directory path contains a special character, the artwork is NEVER found. 

No exceptions. 100% consistent.

Could it be specific to 64-bit Vista?

Thanks,
Peter

Ok, I have an idea. Please try the following:

- remove the custom artwork setting
- shut down/restart SC
- make sure there's no custom artwork setting
- add the artwork.jpg to that setting
- do a rescan

Do you now see the artwork?

I was able to reproduce the issue if I restarted SC after having set that value. With the above procedure I'm able to see the artwork.

change 18822 - don't utf8 decode custom artwork file names (coverArt)

You'll have to remove the custom artwork setting, restart SC and define it again. Please give it a try! Thanks.

I tried what you said, but could not get it to work in build 18806.

However, the latest build (18834) that I just tried works flawlessly, so apparently you found the problem. Now all is good again. Thank you!!!

Peter

thanks for the confirmation!

Verified fixed in 7.0.1 - 19597 r2409 - r23

This bug has recently been fixed in the latest release of SqueezeCenter 7.0.1

Please try that version, if you still see the error, then reopen this bug.

To download this version, please navigate to: http://www.slimdevices.com/su_downloads.html

Reduce number of active targets for SC