Can you attach one of the failing files?

Also, is there anything in the log file?  Enabling player.source debug should provide more info.

(In reply to comment #1)
> Can you attach one of the failing files?
> 

http://rapidshare.com/files/114382089/flac.zip.html

delete link:

http://rapidshare.com/files/114382089/flac.zip.html?killcode=9806479627310970709

I put the file inside a zipfile to ensure the filename would not get mangled.

Could you just attach it to this bug?

Created attachment 3336 [details]
log file

this happens when I try to play the Broca EP.

Created attachment 3338 [details]
flac file inside zip

Jørn, would you double check what character set that your system is using by typing "locale" into the terminal without the quotes?  I just want to make sure it is the same as what SqueezeCenter is reporting.

I also noticed that you are transcoding FLAC to WAV in the log, have you tried turning native FLAC decoding on if your hardware supports it?

The transcoding file location line in your log appears to be broken:
/home/yulquen/fileshare/Audio/Audio_Alpha/B/Broca/Min%FA/Broca%20-%20Min%FA%20-%2002%20-%20Ensemble%20D%27esprit.flac
becomes
/home/yulquen/fileshare/Audio/Audio_Alpha/B/Broca/Min
in the transcoding command.

I am also seeing something odd with my SqueezeCenter in Ubuntu myself.  The file name when using browse by music folder shows:
Broca - Minú - 01 - FusÃ(c)e.flac
While the file name under Song Info shows correctly as:
Broca - Minú - 01 - Fusée.flac
I am still able to play the file with transocding FLAC to WAV but I am hopeful it may provide a clue.

Andy, do you have a moment to take a look?

I can't seem to find it but there was a bug fixed by Michael related to transcoding and non-latin characters.

(In reply to comment #7)
> Jørn, would you double check what character set that your system is using by
> typing "locale" into the terminal without the quotes?  I just want to make sure
> it is the same as what SqueezeCenter is reporting.

Here it is:

LANG=en_US.UTF-8
LC_CTYPE="en_US.UTF-8"
LC_NUMERIC="en_US.UTF-8"
LC_TIME="en_US.UTF-8"
LC_COLLATE="en_US.UTF-8"
LC_MONETARY="en_US.UTF-8"
LC_MESSAGES="en_US.UTF-8"
LC_PAPER="en_US.UTF-8"
LC_NAME="en_US.UTF-8"
LC_ADDRESS="en_US.UTF-8"
LC_TELEPHONE="en_US.UTF-8"
LC_MEASUREMENT="en_US.UTF-8"
LC_IDENTIFICATION="en_US.UTF-8"
LC_ALL=



> 
> I also noticed that you are transcoding FLAC to WAV in the log, have you tried
> turning native FLAC decoding on if your hardware supports it?

the reason I have had the flac to wav transcoding on, is that softsqueeze
plays my 48KHz FLACs to slow (plays them at 44,1KHz) if there is no transcoding.
I have experienced this on all pc's I have used softsqueeze on, both home,
at work and at friends.thats why I had enabled it.

anyway, when turning off the flac to wav transcoding, all the troubled files
load fine! so now at least you know where the problem lies.Ill just leave the
transcoding off for now, its the least of two evils.

 
> The transcoding file location line in your log appears to be broken:
> /home/yulquen/fileshare/Audio/Audio_Alpha/B/Broca/Min%FA/Broca%20-%20Min%FA%20-%2002%20-%20Ensemble%20D%27esprit.flac
> becomes
> /home/yulquen/fileshare/Audio/Audio_Alpha/B/Broca/Min
> in the transcoding command.
> 
> I am also seeing something odd with my SqueezeCenter in Ubuntu myself.  The
> file name when using browse by music folder shows:
> Broca - Minú - 01 - FusÃ(c)e.flac
> While the file name under Song Info shows correctly as:
> Broca - Minú - 01 - Fusée.flac
> I am still able to play the file with transocding FLAC to WAV but I am hopeful
> it may provide a clue.
> 
> Andy, do you have a moment to take a look?
> 

(In reply to comment #8)
> I can't seem to find it but there was a bug fixed by Michael related to
> transcoding and non-latin characters.

Andy, possibly you were thinking of bug 7963?

That's the one.

Steven, do you also see the different results in Windows or Mac, or is it just in linux?

Different from Browse music folder and Song Info, that is.

I can reproduce this on Linux, but not Mac.  Did not test Win32.

I only see the behavior with Ubuntu.  I tried both Mac OS X and Win XP.

Another thing to note is when I try transcoding with the example file my log shows the file name as "Broca - Minú - 01 - FusÃ(c)e.flac" just like the music folder but it still plays.

I also saw it on Ubuntu.

Steven, could you try to repro on 7.0 please to understand if this is a new problem, or something that has been with us for a while and doesn't affect many people?

Sure

So I forced to 7.0 using the Synaptic Package Manager and I no longer see the character issue in the music folder or anywhere else in the browser.

Now for the weird part, I forced back to 7.0.1 and I still don't see the character issue in the browser!  I even tried rescanning the music library both under 7.0 and 7.0.1 and I can no longer recreate the issue I saw previously.

I still see the odd character issue in the player log however but I was always able to play transcoded flac just the same.

Andy, when you say you can reproduce are you referring to the character display issue or not being able to play the flac transcoded or both? 

I think the name was fine (from tags) but the file failed to play with the same truncated-filename error in the logs.  I need to investigate further.

Thanks, Andy.  It looks like right now you're the only one here seeing this, so please let us know what you learn so we can make a decision about 7.0.1.

The symptoms Stephen's seeing are not serious enough to make me want to hold up release.

Just a quick note: whenever testing different version, make sure you not only wipe the DB, but server.pref too. That file now is stored in utf8, which it wasn't before. This change lead to some odd behaviour in file path handling.

The root cause is this new line of code:

$filepath = Slim::Utils::Unicode::utf8decode_locale($filepath);

It converts the filename from "Broca - Min� - 01 - Fus�e.flac" to "Broca - Min".

I've checked in a fix that works for me in change 19663.  It will check if the original filename exists before trying to utf8 decode it.

QA: Please also retest bug 7963.

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

(In reply to comment #25)
> 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
> 

its ok now!

Jorn - did you ever update to 7.2.x? If so, is it still working for you? Because we've got another bug 9488 about the axact same issue, but _with_ the fix used here. To satisfy those users, we have to remove this fix again. Doesn't make much sense to me. Thus if you had a chance to test 7.2.1, I'd be happy to know whether it's still working for you or not.

Reduce number of active targets for SC