GNOME Bugzilla – Bug 97687
no longer sorts alphabetically
Last modified: 2009-08-15 18:40:50 UTC
I start rhythmbox. I add my library. I quit rhythmbox. I restart rhythmbox, and the 'artists' and 'albums' fields in the browser are not sorted alphabetically (but they are sorted the same way every time). See http://www.stanford.edu/~jbarnett/Screenshot.png to see the lack of alphabetical-ness (E,B,E,B,D in artists, E,e,2,F,F in albums) I do have both artists and albums in the a-e ranges... this is with latest CVS
Exactly the same here, would be cool to fix that before release... When the lib is empty and that i add a bunch of new files, they are sorted correctly in the Artist/Album treeview. I haven't been able to find a way to reproduce, but at some point, the sorting gets screwed up.
Please check whether attached patch fixes the prob
Created attachment 12172 [details] [review] patch
And if it doesn't, please check whether you can repro 97978 with Daniel's testcase.
I applied the attached patch, rebuilt and reinstalled rhythmbox, and my library was still incorrectly sorted when I restarted rhythmbox. But then I deleted my library, and re-added it, and now I can't get the bug to reproduce. So the patch fixed it :) you just need to regenerate the library.
Rockin'! :) thx for testing
Still not working for me... Something that might be related (really not sure): after a g_utf8_collate_key (in setting the artist key for instance), i have garbage in the value Anyway, the keys used for sorting are not correctly saved in the XML and thus sorting is wrong.
If i'm the only one having it, let's not block RB's release for me ;)
OK good news, a workaround: export LC_COLLATE="C" rhythmbox fixes it :) We now need to fix it properly: 1- detect LC_COLLATE is non utf8 (or not set) 2- set it 3- throw some warning Then we're fine (hopefully)
I am still getting (with the above patch applied via CVS) the described behaviour. What should I expect in the RB_NODE_PROP_NAME_SORT_KEY? I just appear to have 'garbage' as Olivier described above.
Mark: You'll need to remove your lib, and recreate it again... Can you confirm if this works? (RB_NODE_PROP_NAME_SORT_KEY should contain a key encoded with g_utf8_collate, so it looks a bit weird, that's normal)
More information on this one: 1- Tests with dfferent LC_COLLATE ================================= * export LC_COLLATE="fr_FR.UTF-8 --> works perfectly * export LC_COLLATE="fr_FR.iso885915" --> sorted but the key is _not_ encoded -> Jorn: this looks like your problem * export LC_COLLATE="" --> broken (my first behaviour) 2- Tests with g_utf8_validate on the generated key ================================================== * export LC_COLLATE="fr_FR.UTF-8" --> OK * export LC_COLLATE="fr_FR.iso885915" --> OK (value is not encoded) * export LC_COLLATE="" --> OK (still lots of garbage in the value :/ ) Marco: The g_utf8_collate_key falls in the first #define ;)
Confirmation that what I did was ... a) Delete my original library b) Start rb c) Import the tracks again (all go in the correct order) d) Close rhythmbox e) Reopen f) Order is all 'crazy' again! For example ... Imported artist order (before close) American Music Club Bill Wells and Isobel Campell High Llamas Various Wedding Present, The After shutdown .... High Llamas Bill Wells and Isobel Campell American Music Club Various Wedding Present, The So the solution is still not there. However, if I follow the solution above and add the entries when the LC_COLLATE is set, then the order is correct. Once the order is incorrect, the LC_COLLATE doesn't fix it.
So, what I propose as workaround: at startup, make a func which checks for LC_COLLATE if it strstr contains "UTF-8", proceed. If it doesnt, warn, and set the value to (strstr ($LANGUAGE, "UTF-8") ? $LANGUAGE : "%s.UTF-8", $LANGUAGE)), which will work in most cases, I think.
Created attachment 12281 [details] [review] workaround implementation
all of the sudden I'm seeing this again in the debian unstable package of 0.4.0.... starting with LC_COLLATE="C" doesn't help, either, nor does LC_COLLATE="en_US".... where can I look for more information... this wasn't happening until I deleted and re-added some songs to update tag information (since RB seemed not to auto-update changed id3 tags), but now I can't get it fixed again :-\
I'm still seeing this bug in both the debian package of 0.4.0 and the release tarball of 0.4.1 compiled myself. It was fixed for a while, but now it has resurfaced, not sure if its a configuration issue or not, but it still happens if i rm -r ~/.gnome2/rhythmbox and ~/.gconf/apps/rhythmbox and start over.
Hmm this is just weird :/ You can try with LC_COLLATE="en_US.UTF-8" but that's what RB already do... No idea.
strange, LC_COLLATE="en_US.UTF8" fixed it. I'm not actually sure why that is, but I'll look at the area related to the 'workaround implementation' patch and see what old_collate and new_collate end up being.
when I run with setting LC_COLLATE, i get : new_collate=LC_COLLATE=en_US.UTF-8 old_collate=LC_COLLATE=en_US.UTF-8 when I run without setting LC_COLLATE, i get : new_collate=LC_COLLATE=en_US.UTF-8 old_collate=LC_COLLATE=(null) I don't really know why it's not working though... but I can reliably reproduce the error when LC_COLLATE is unset/set to C/set to en_US upon running rhythmbox, and reliably reproduce success when it is set to en_US.UTF-8. so for now i have just mv'ed rhythmbox to rhythmbox.bin, and created a shell script rhythmbox that runs rhythmbox.bin under LC_COLLATE=en_US.UTF-8
Have duplicate this in Mandrake 9.1 ppc, exactly the behaviour described above. On rh9 x86, behaves as expected.
This works fine here. Can you still reproduce this using the Rhythmbox CVS HEAD?
Yeah, I still get this behavior using CVS HEAD 2003-05-22
Would like to have someone else verify this for me. As of cvs HEAD 2003-08-03 I see this issue as resolved. -harshy
unfortunately, I still see this using 2003-08-03 cvs HEAD. the only difference I can think of that I have is that I change data/node-views/rb-node-view-songs.xml to sort by artist instead of track as default. I don't see why that should change anything though...
although i just realized i don't change the "sort-order" xml property, just the default-sort-column property. I'll play around with this and see if I can't get it to work and get back to you.
ok, for whatever reason it is now working properly with CVS HEAD 2003-08-10. this is both with and without my change to node-views/rb-node-view-songs.xml. i'm happy. marking as closed