Possibly related to bug 4470.

What is the name of the folder, by the way?

Yes, definetely looks like it's the same bug.
Have a number of those; as an example, this is one:

������ ��������� � �����a ���������� - ������� ������(1998)[FLAC]

Not sure if this is going to be visible, so I've attached tho screenshots: the music folder as viewed via WebUI, and the windows explorer view.

Created attachment 1713 [details]
directory as viewed via WebUI

Created attachment 1714 [details]
directory as viewed via Windows Explorer

Any news/expectations?

Yuly, are you able to add any brand new unicode-named files or folders to Slimserver?

The reason I ask is that I suspect this is another symptom of bug 2475.

Oh, yes! I do it on a daily basis. New unicode-named folders with unicode-named files are recognized during rescan, without covers.

Yuly, would you take the time to upload a small archive file maintaining the directory structure you use that exhibits the behavior?

Created attachment 1773 [details]
Sample music library

Attached is a zip archive with 3 directories in it, each representing one album, with 1 track.
One directory uses is named using latin characters, and two are named using cyrillic.
I have pointed my slimserver to this directory structure as my library, stopped the server, cleared the cache directory and restarted. It picked my new library, and the bug is apparent: no covers or thumbs in the cyrillic-named albums

BTW, the same music library can be used for bugs 3727 and 4630 illustration/verification.
How do I create a link to this upload in those?

Yuly, thank you for uploading the files. However I think the archiving process changed the name of the files. Since the names of the files were changed I am not able to reproduce the problem. You may want to try again with a different archiver such as RAR. If I do rename the files based on the tag information I run into a situation that Slimserver will not see the files at all let alone the artwork. Investigating further.

Yuly, don't bother uploading new files. The problem I was seeing had to do with the Regional and Language settings in Windows. Investigating further.

(In reply to comment #11)
> Yuly, thank you for uploading the files. However I think the archiving process
> changed the name of the files. Since the names of the files were changed I am
> not able to reproduce the problem. You may want to try again with a different
> archiver such as RAR. If I do rename the files based on the tag information I
> run into a situation that Slimserver will not see the files at all let alone
> the artwork. Investigating further.
> 

Steven,
Just in case it matters: my Regional settings are set to <tab-option>: Regional-Russian; Advanced-Russian

Yuly, I was just about to ask you what your Regional setting are, you must be reading my mind ;) 

(In reply to comment #13)
> Steven,
> Just in case it matters: my Regional settings are set to <tab-option>:
> Regional-Russian; Advanced-Russian
> 

I am now able to reproduce the behavior.

1. In Win XP set "Language for non-Unicode programs" to "Russian" To do this go to Control Panel -> Regional and Language Options -> Advanced Tab
2. Download "Sample music library" above and expand into a directory that Slimserver sees
3. Navigate to the new files in Slimserver using Music Folder or Rescan Music Library
4. Notice the new files are available but does not display cover artwork

If I switch the "Language for non-Unicode programs" back to "English" the files in question disappear from Slimserver altogether and cannot be seen using the browse Music Folder. The file names on the desktop appear fine but the tags do not.

If I try to open the archive while I have "Language for non-Unicode programs" set to "English" the file names in the archive become garbled. These files will not load in Slimserver.

I am going to update bug 4470 as a duplicate as this one instead of bug 2475.

Chris, back to you.

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

Bump!
Any plans for fixing this?

And another bump:( Will this be fixed someday? 

We'll look at it for 6.5.4.  Thanks for the reminder!

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

Yuly - before I start digging - do you still see this issue with the latest SC7?

Yes, I just installed the latest 7.0, and the problem is still there.

Are you using an all Windows system? I just tried to reproduce the issue with a Hebrew folder name and it did work fine for me.

Wallace - could you try to reproduce this? I'm sure you have some Chinese test machine around? Thanks!

(In reply to comment #23)
> Are you using an all Windows system? I just tried to reproduce the issue with a
> Hebrew folder name and it did work fine for me.
> Wallace - could you try to reproduce this? I'm sure you have some Chinese test
> machine around? Thanks!

Yes, the machine is a Windows 2003 SP2 with cyrillic locale:
SqueezeCenter Version: 7.0 - 16286 - Windows Server 2003 - EN - cp1251
Server IP address: 192.168.11.6
Perl Version: 5.8.8 MSWin32-x86-multi-thread
MySQL Version: 5.0.22-community-nt 

Platform Architecture: 586

Hostname: yuly-home-new

Server Port Number: 9000

Total Players Recognized: 3

Cache Folder: C:\Documents and Settings\All Users\Application Data\SqueezeCenter\Cache

Plugin Folders: C:\Program Files\SqueezeCenter\server\Slim\Plugin, C:\Program Files\SqueezeCenter\server\Plugins

Yuly - please delete your scanner.log, turn on artwork=debug and run a scan again. Then upload scanner.log to this report. Thanks.

Created attachment 2669 [details]
scanner.log

This is a scanner log with artwork debug enabled. A test library was used, with 3 folders: one named with latin characters and two - with cyrillic.

It looks as if the file name got incorrectly encoded in Slim::Music::Artwork::getImageContentAndType

Do you have ActivePerl installed? Could you try commenting out the following line (line 143 in Artwork.pm) and run slimserver.pl from a command window?

Created attachment 2680 [details]
scanner log with line 143 in artworks.pm commented

This has done the trick! Disabling this line made squeezecenter correctly recognize and display the artwork files in the folders with cyrillic names.

Great news! Now let's try to make this a reasonable patch. Would this change work:

Index: /Users/mh/Documents/workspace/trunk/server/Slim/Music/Artwork.pm
===================================================================
--- /Users/mh/Documents/workspace/trunk/server/Slim/Music/Artwork.pm	(revision 16375)
+++ /Users/mh/Documents/workspace/trunk/server/Slim/Music/Artwork.pm	(working copy)
@@ -139,7 +139,7 @@
 	# path into the current locale.
 	my $locale = Slim::Utils::Unicode::currentLocale();
 
-	if ($locale ne 'utf8') {
+	if ($locale ne 'utf8' && !-e $path) {
 		$path = Slim::Utils::Unicode::encode($locale, $path);
 	}


This would only apply the encoding if the file can't be found without.

(In reply to comment #29)
I must confess I do not know how to apply this patch. Can you provide me a link to some instructions?

> Great news! Now let's try to make this a reasonable patch. Would this change
> work:
> Index: /Users/mh/Documents/workspace/trunk/server/Slim/Music/Artwork.pm
> ===================================================================
> --- /Users/mh/Documents/workspace/trunk/server/Slim/Music/Artwork.pm   
> (revision 16375)
> +++ /Users/mh/Documents/workspace/trunk/server/Slim/Music/Artwork.pm   
> (working copy)
> @@ -139,7 +139,7 @@
>         # path into the current locale.
>         my $locale = Slim::Utils::Unicode::currentLocale();
> -       if ($locale ne 'utf8') {
> +       if ($locale ne 'utf8' && !-e $path) {
>                 $path = Slim::Utils::Unicode::encode($locale, $path);
>         }
> This would only apply the encoding if the file can't be found without.

> I must confess I do not know how to apply this patch. Can you provide me a link
> to some instructions?

In this simple case it's enough to replace the line marked with a "-" with the one marked with "+":

> > -       if ($locale ne 'utf8') {
> > +       if ($locale ne 'utf8' && !-e $path) {
> >                 $path = Slim::Utils::Unicode::encode($locale, $path);

...and uncomment the line you commented out previously :-). We're just adding a test whether the file does exist or not, before we try to "fix" the path using some encoding. "-e" is an operator to test a file's existence. Is this ok?

Otherwise something like windiff might help:
http://support.microsoft.com/kb/159214/en-us

Worked for me!

Steinar - you reported bug 3245 which lead to the above encode() line. Could you please test this patch, whether it would break your system? Otherwise I'd like to get it in for the 7.0 release. Thanks!

Works for me.

change 16425 - thanks for testing!

This bug is being closed since it was resolved for a version which is now released!  Please download the new version of SqueezeCenter (formerly SlimServer) at http://www.slimdevices.com/su_downloads.html

If you are still seeing this bug, please re-open it and we will consider it for a future release.

I'm still seeing this bug with flac files with embedded cuesheets.  But, in this case, it's not just artwork that is effected, but audio playback as well (which also completely fails.)  The bug involves mangling of filenames on UTF8 encoded file systems during the scanning process...i.e. the filename is "double utf8 encoded" when the filename is posted to the db.  Subsequent attempts to extract artwork or play back audio from the incorrectly formed pathname file.

Should this bug be kept open, or should this be considered a new bug?

This bug was specifically about the artwork; it sounds like your new bug is more pervasive, Gordon.  Could I ask you to file a new bug for it?  Thanks.