Vaqskal

Does the same thing happen with the Default skin?

(In reply to comment #1)
> Vaqskal
> Does the same thing happen with the Default skin?

Yes, I have tested that now.

QA to try to reproduce.  Andy notes that this has been fixed in the past; Mysql requires a special swedish setting, but this is done if the server is set to swedish.  Related to bug 5443.

(In reply to comment #3)
> QA to try to reproduce.  Andy notes that this has been fixed in the past; Mysql
> requires a special swedish setting, but this is done if the server is set to
> swedish.  Related to bug 5443.

Yes, I am quite sure it has worked in the past, but I cannot tell exactely when it was broken again (perhaps when I uppdated to 7.2.2 nightly recently?).

The behaviour persists after updating to latest 7.3 nightly.

Below are the details after the update:
SqueezeCenter-statusVersion: 7.3 - 24151 @ Sat Nov 29 03:01:22 PST 2008

Värdnamn: Musikmaskinen

Serverns IP-adress: 192.168.1.4

HTTP-serverns portnummer: 9000

Operativsystem: Windows XP - SV - cp1252 

Plattformsarkitektur: 586

Perl-version: 5.8.8 - MSWin32-x86-multi-thread

MySQL-version: 5.0.22-community-nt

Totalt antal anslutna spelare: 4

I might add that the "Swedish" characters (åäöÅÄÖ) do not show up at all on the scroll wheel on the Controller (7.3 r3437). (I, however, cannot remember that they have ever shown up there.)

A swedish user sent me the following comment:

"The version 7.2 SqueezeCenter sort the Swedish letters in the correct
alphabetic order, ABC…O…..ZÅÄÖ. The three latter is a Swedish “specialty”
only shared with other Nordic countries (and Ö with Germany)  J
 
In the last version (7.3) your program sort the letters (in music folder for
instance) in order AÄÅ………OÖ…Z. For example, the three artists “Pojkar”,
“Police” and “Pökhus” should be in this order (and is in ver 7.2) but now
comes in order “Pojkar”, “Pökhus” and “Police”. This is incorrect and rather
irritating."

Andy - didn't we add some code to handle nordic languages differently? I thought there was some change on the DB level.

OK, what probably happened was that schema_8_up was run on upgrading to 7.3, and it changed the collate on all tables to utf8_general_ci.

To fix the problem, try this:
Go to Settings.
Change language to English.
Change language back to Swedish.

That should reset the collate values for the database.

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

I think there must be a "general" solution to this problem since people tend to have albums/artists/bands... from many countries nowadays.

I agree very much to let the database handle the collation (if possible), putting the actual "work" where it belongs. Also I think switching the collation to whatever "home language" a user has selected is a good idea. (Though bad for me, since I prefer English but live in Germany and kinda got used to the German collation sequence. Adding an extra "database collation" selector would add to the complexity, so I can live without.)

Is it done this way already? Reading Andy's comment I think the answer is "yes"?

Still there is a problem with this "getting rid of accents" logic: Even if displaying "É" as an extra letter at the end (SC set to English), the "E" shouldn't be missing. It confuses reading "A B C D F ..." and finding all albums starting with "E" under "É".

It might be nice to be able to SEARCH for "Équinoxe" by lazily typing "equinox" but I think for display and sorting purposes it's a bad idea trying to handle that manually in the code. Some accented letters in some languages sort like "the main letter without accent" whereas some have their own place in the alphabet, like in nordic languages, Dutch, German, etc. Every country has its own sorting rules, Germany has even two: (ä,ö,ü,ß=a,o,u,ss or ä,ö,ü,ß=ae,oe,ue,ss), Swedish uses ...z,å,ö,ü and ü=y and so on. How would we sort Thai? Chinese? Japanese? Russian? Polish? ...

Without having collation tables for each and every language, we should just let the database do it (a good database usually has collation rules), display "as returned", but still use some logic for "easy entry" into search forms.

So for my bug 10413 for example, I'd expect it to return "A B C D E F ... É" or maybe even "A B C D E É F ...".

Did anyone ever check out mySQL's "utf8" collation? If this was sorted like UTF16 or UTF32 where more "exotic" languages usually have their own range, it might help.

Validated this bug. Å is sorted at the top of my list (tracks), when it should be sorted after Z. 

(In reply to comment #8)
> OK, what probably happened was that schema_8_up was run on upgrading to 7.3,
> and it changed the collate on all tables to utf8_general_ci.
> 
> To fix the problem, try this:
> Go to Settings.
> Change language to English.
> Change language back to Swedish.
> 
> That should reset the collate values for the database.
> 

This fixed it for me in the web UI on 7.3.1 - 24324.

A change of language on the controller (FW 7.3 r3476) as suggested and thereafter a restart did, however, not fix the problem with sorting or the missing characters on the wheel on the controller.

Ross - is your last comment with or without the change Andy proposed?

(In reply to comment #13)
> Ross - is your last comment with or without the change Andy proposed?
> 

I apologize. My last comment was without the change Andy proposed. Switching the language as Andy suggests fixes the sort order in my test. 

> I apologize. My last comment was without the change Andy proposed. Switching
> the language as Andy suggests fixes the sort order in my test. 

Can you reproduce comment #12?

(In reply to comment #12)
> A change of language on the controller (FW 7.3 r3476) as suggested and
> thereafter a restart did, however, not fix the problem with sorting or the
> missing characters on the wheel on the controller.

I can't reproduce this. When I switch the language to Swedish on my Controller, the Swedish characters are sorted properly. They are sorted incorrectly until I switch the language. 

Then we can consider this fixed? Thanks!

Thank you Michael!

Sorry for being persistent.

I concur that the sort order is now fixed on the Controller as well.

But the Swedish characters do not appear at all on the typing wheel on the Controller (at least in the wheels used for searching artists and the wheel for setting the player name). I did another change of language on the Controller as suggested and thereafter a restart. I am now on FW 7.3 r3692.

Should the wheel issue perhaps be entered as a separate bug for it to be addressed (since it is not related to the sort order)?

Thanks for the feedback!

> Should the wheel issue perhaps be entered as a separate bug for it to be
> addressed (since it is not related to the sort order)?

Feel free to do so (if it doesn't exist yet). But you know that you can use the transcript (or whatever it's called) for those characters: o instead of ö etc.

(In reply to comment #20)
> > Should the wheel issue perhaps be entered as a separate bug for it to be
> > addressed (since it is not related to the sort order)?
> 
> Feel free to do so (if it doesn't exist yet). But you know that you can use the
> transcript (or whatever it's called) for those characters: o instead of ö etc.
> 

Thanks for the reply.

I filed a separate bug report, Bug# 10650.

This bug has been fixed in the 7.3.3 release version of SqueezeCenter!

If you haven't already. please download the new version from http://www.logitechsqueezebox.com/support/download-squeezecenter.html 

If you are still experiencing this problem, feel free to reopen the bug with your new comments and we'll have another look.

(In reply to comment #0)
> 1. Artists and Albums containing "Swedish" characters (åäöÅÄÖ) are not
> sorted correctly in the web UI, using Fishbone, (or on the Controller or the
> SB3 display). They are sorted as if the "umlaut" - i.e. the dots or circle -
> did not exist. They should be sorted last.
> 
> 2. In Artist and Album view in the web UI, using Fishbone, those characters do
> not appear in the alphabetic list on top (although I have albums and artists
> which start with those characters). When browsing Artist / Various Artists
> those characters do appear correctly (at the end of the alphabet) in the
> alphabetic list on top (but using the link from them will get you to their
> "naked" equivalent, i.e. the link for Ä will take you to A).
> 
> Below are my details:
> SqueezeCenter-version: 7.2.2 - 23974 @ Sat Nov 22 02:02:33 PST 2008 - Windows
> XP - SV - cp1252
> Serverns IP-adress: 192.168.1.4
> Perl-version: 5.8.8 MSWin32-x86-multi-thread
> MySQL-version: 5.0.22-community-nt 
> 
> I am using Swedish XP with Swedish keyboard layout. The language in SC and on
> the Controller is set to Swedish ("Svenska"). I use the Fishbone skin. I have
> the Custome Browse plugin installed.

I am afraid that this issue is back again with 7.5.2 - r31077. My setup is otherwise the same.

I am now only using the default skin and this time the Artist / Various Artists menu behaves the same as the Artist and Album views, i.e. the "Swedish" characters (åäöÅÄÖ) are not sorted last and they do not appear in the alphabetic list on top. Otherwise the symptoms are the same.

The cure is also the same: Switch language to English and switch back to Swedish.

Oh, have to write a comment to reopen the bug report. The actual comment is above.

The cure for this bug (switching language) seems to have invoked bug #15116 and I get a lot of error messages like this one:

[10-07-25 21:23:29.2346] Slim::Schema::Storage::throw_exception (82) Error: DBI Exception: DBD::mysql::st execute failed: Illegal mix of collations (utf8_general_ci,IMPLICIT) and (utf8_swedish_ci,IMPLICIT) for operation '=' [for Statement "UPDATE tracks_persistent,track_statistics set tracks_persistent.rating=track_statistics.rating where tracks_persistent.url=track_statistics.url and track_statistics.rating>0 and (tracks_persistent.rating!=track_statistics.rating or tracks_persistent.rating is null)"]

I closing this on the basis that the original problem was indeed fixed. A new problem has since arisen (with much the same symptoms) and this deserves a new bug. I suggest that bug 13600 is the appropriate place to follow up with this.