Created attachment 1613 [details]
example of a cue file that has issues, with special characters

Created attachment 1614 [details]
attached as a bin, so as to perhaps save the file name 

the file name should be "M�tley Cr�e - Girls, Girls, Girls.cue" to test this bug accurately.

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

I was able to reproduce the behavior on Win XP. However it seems that removing accented characters from just the audio file name and the reference inside the cue fixed the problem. I did not need to remove accented characters from the cue file name itself.

For example:
M�tley Cr�e - Girls, Girls, Girls.cue
M�tley Cr�e - Girls, Girls, Girls.flac
FILE "M�tley Cr�e - Girls, Girls, Girls.flac" WAVE (Line inside cue)
did not list anything in Slimserver when the cue file was selected.

However when changed to:
M�tley Cr�e - Girls, Girls, Girls.cue
Motley Crue - Girls, Girls, Girls.flac
FILE "Motley Crue - Girls, Girls, Girls.flac" WAVE (Line inside cue)
worked in Slimserver as expected.

Could this have something to do with bug 2475?

(In reply to comment #5)
> Could this have something to do with bug 2475?
> 

I don't think so because the flac file is available in SlimServer.  If the characters in the name were not in the currently selected code page the flac would not be available in SlimServer at all.

I've had the above problem for some time now...  For a while it appeared to
be fixed in the nightly release, but then got broken again.  Sadly, I
didn't save the version that worked.  After digging through the code
a bit and doing some hacking...

I found that making the two changes below fixes the problem.  Then run
a scan manually (don't use the windows scanner.exe).

Ex:
         \Program Files\SlimServer\server\scanner.pl --wipe <your music dir here>

The first fix below seems to correct the encoding of the cdimage filename string, while the
second fix prevents the same string from getting truncated later(!).  Interestingly, the
second fix is only needed when I scan a large collection.  When I run
the scanner on a few test files, only the first fix is necessary.  I have no idea
why this is the case, but the combination works for me.  Hopefully someone else
can figure out the right way to fix this!

George

1) \Program Files\SlimServer\server\Slim\Utils\Misc.pm:

	# Bug: 1786
	#
	# Work around a perl bug that exists in 5.8.0, 5.8.1 & 5.8.2? - where
	# a join() can return garbage because it's internal scratch space
	# wasn't properly cleared with a UTF8 string that previously went
	# through it. The call to $uri->file() below contains such a join, and
	# was causing bogus data to be returned on OSX 10.3.x systems.
	#
	# See
	# http://lists.bestpractical.com/pipermail/rt-devel/2004-January/005283.html
	# for some more information.
#	if ($] > 5.007 && $] <= 5.008002) {

		$url = Slim::Utils::Unicode::utf8off($url);
#	}

2) \Program Files\SlimServer\server\Slim\Formats\Playlists\CUE.pm:

		my $enc = Slim::Utils::Unicode::encodingFromString($line);
		# Prefer UTF8 for CUE sheets.
#		$line = Slim::Utils::Unicode::utf8decode_guess($line, 'utf8', $enc);
$line = Slim::Utils::Unicode::utf8decode_locale($line);
		# strip whitespace from end
		$line =~ s/\s*$//;

Passing to Andy for review.

George, was this patch for 6.5.x or for trunk (7.0)?

Hi Chris,

This patch was for 6.5.5 from a couple of days ago.

I tried 7.0 a couple of weeks ago, but didn't explicitly check
to see if it had the same problem.  However, I now notice a Logs
directory under the server directory that looks like it was left over from
my 7.0 install(?).  From the scanner.log it looks like it does
have the same problem.

Note: I haven't thoroughly investigated some of the
reasons why my changes work, or if they break anything else.  I
just hope it helps someone else get a leg up on providing
a real fix.

Thanks!

George

Well if Andy judges there is any risk, we could defer this to 7.0.1 to give a bit of extra time for testing your patch.

Due to bug #5884, the workaround that I proposed doesn't work quite right.  Here is
what I suggest now:

#1 Rename scanner.exe to scanner_exe.old (so it won't run)
#2 Rename \Program Files\SqueezeCenter\server\CPAN\URI.pm to URI_OLD.pm
#3 Install ActiveState perl, if you haven't already
#4 Modify Misc.pm and CUE.pm as above

Note:  I suspect that this procedure will work for 6.5.x as well
as 7.0a1, but I have only tested it for the latter.

Now you can do a clear & rescan from the web interface and it will run
the scanner using the perl interpreter *and* with the fixes
to pick up the accented characters.

Steps #2 works around a new problem caused by bug #5884 that screws up
the now playing display for any cue albums with single quotes in them.

Anyway, this works for me...

George

A user re-opened bug 2475 with what looks to me like probably this bug instead.  I've copied his comment from that bug:

Hi,

I updated from slimserver 6.5.3 to 6.5.4 in the process of moving my slimserver
to an different machine and after the initial scan to discover my music files,
found that 25 of my albums had gone missing. This is the same number that have
foreign accented characters in their file names. e.g.: 

Acadamy of Ancient Music, Richard Egarr - Händel  Concerti grossi Op.3, Sonata
a 5.cue
Beethoven - Beethoven Symphonies Nos.3 & 8 - Minnesota Orchestra - Vänskä.cue
Dvorák, Antonín - Cello Concerto, Dumky Trio.cue
Kölner Kammerorchester, Helmut Müller-Brühl - J.S. Bach - Messe in h-Moll,
BWV 232 (CD2).cue

etc. etc.

My library is one flat directory of EAC-generated CUE sheets with a single WAVE
file corresponding to each CUE sheet. Real simple. Foobar2000 can find them all
and play them all (yes, I checked).

So I tried "clear library and rescan everything" several times with various
debug options turned on and found no useful error messages. In the end, I found
this thread and reverted back to 6.5.3 and the initial scan found all my music
again!

After reverting slimsever the following is my system (was 6.5.4 when the
problem showed) and the code page is and was cp1252. All music is stored on an
NTFS formated drive intialized from within Windows XP.

SlimServer Version: 6.5.3 - 12376 - Windows XP - EN - cp1252
Server IP address: 192.168.1.111
Perl Version: 5.8.8 MSWin32-x86-multi-thread
MySQL Version: 5.0.22-community-nt 

Regards,

Charles Razzell

Can anyone confirm that this bug only occurs under Windows?  The attached cue sheet is read OK on OSX, although I had to manually rename the download file so the filename was probably not encoded the same way.  How about providing a zip file containing the cue sheet?

Also, can someone please attach a log file with scan.scanner and formats.playlists set to debug?

Bump, this bug won't be fixed unless someone responds to my question above.

I've had it also under linux a while back. I've since renamed all my mp3 files to remove accented characters (folder names too). Tags inside the files don't cause any problems. Don't know about 7.x, never tried it.

I've recently checked in a bunch of changes which care about non-latin character stuff. Could anybody confirm they fixed/did not fix this issue? Please use latest trunk builds to reproduce. Thanks

Anybody out there still able to reproduce this issue with the latest 7.0.1 build? Can we consider this fixed?

it works for me finally. Thank u so much for finally resolving this bug. Chris

(In reply to comment #19)
> it works for me finally. Thank u so much for finally resolving this bug. Chris
> 

Closing bug.  Please open a new bug if you find any other errors

Reduce number of active targets for SC