GNOME Bugzilla – Bug 406043
Track Order not working
Last modified: 2008-03-11 16:14:43 UTC
I'm using Banshee 0.11.6, last version found on Ubuntu Feisty. Track order simply doesn't work as expected. I tried 2 setups, one with local library (a sound track listing with different artists name) and one album with same artist for every song exported from a remote mt-daapd server. Results are that neither of the two order correctly, whereas Banshee 0.11.1 (i think) included in edgy does correctly sort songs. 0.11.1 anyway doesn't correctly import track number metadata from mt-daapd remote server, whereas 0.11.6 does. I can't understand really what key is used to sort track in 0.11.6, since it seems to me real random. To help debugging I posted on my web server 3 different screenshots, one for each track order selection (i think one should be ascending, the other descending and a 3rd "no order"). They are at: http://jeeper.afraid.org/images/rsgallery/original/Schermata-Banshee_-_Riproduttore_musicale.png http://jeeper.afraid.org/images/rsgallery/original/Schermata-Banshee_-_Riproduttore_musicale-1.png http://jeeper.afraid.org/images/rsgallery/original/Schermata-Banshee_-_Riproduttore_musicale-2.png UI is in Italian, this anyway won't hurt. Tracci(a) = Track; Artista = Artist; Titolo = Title; Durata = Time; Giudizio = Rate.
I've got the same issue. I find this issue happens also when using my iPod. I'm using Banshee 0.11.6 also.
Created attachment 82353 [details] Screenshot of track order on iPod Screenshot of track order on iPod
Just checked svn version, strange issues here: at least on one album (not the one i posted screenshots above) does display with the right track order, ascending and descending. The one I posted above still doesn't work. The strange thing is: the one who works, works only when imported in music library. When shared through a remote mt-daapd server even this album doesn't show correctly ordered (it shows up with 3 different random orderings). I'm trying this on Ubuntu Edgy. Anyway big improvement over 0.11.1 since track order is shown on shared music (yes i'm repeating myself).
This can also be observed in 0.11.7 as well.
And 0.12.0 too. Just tried today in Ubuntu Feisty.
Created attachment 84502 [details] [review] Patch that fixes the sorting by track number bug.
Just tried that, finally works. Thank you very much. Bug fixed for me.
That patch definately helps. If you sort by Track only, it works like a charm. However, if you go to say, sort by album, the tracks don't get sorted by track within each grouping of albums.
I was not able to replicate the issue with the album / track sorting. Please check to see if you have the most recent version of banshee/src/Core/Banshee/Banshee.TrackView.Columns/AlbumColumn.cs from SVN. The secondary sort by track number is being handled at line 71 and should read: return v != 0 ? v : TrackNumberColumn.ModelCompareBase(model, a, b, trackAscending);
I was testing against 0.12.0. That line seems to be there as you described. I'll have to retest, and take some screenshots.
I think I've tracked down the issue. The problem is that in AlbumColumn.cs, it was checking stuff in this order: UriColumn.ModelCompare(model, a, b, true); StringUtil.RelaxedCompare(model.IterTrackInfo(a).Album, model.IterTrackInfo(b).Album); TrackNumberColumn.ModelCompareBase(model, a, b, trackAscending); So I'm guessing that UriColumn almost always evaluates to 1 or -1, so the other ones are hardly ever used. This seems to work fine for local stuff... but if you go onto something hosted by mt-daapd, the first comparison seems to not be valid anymore. I was able to address this by changing it to: StringUtil.RelaxedCompare(model.IterTrackInfo(a).Album, model.IterTrackInfo(b).Album); TrackNumberColumn.ModelCompareBase(model, a, b, trackAscending); UriColumn.ModelCompare(model, a, b, true);
Created attachment 84629 [details] [review] banshee-0.12.0-trackorder.patch Patch with suggested changes. I also took the liberty of changing the usage of v = v != 0 ? blah : v; It seemed a bit dense to me on my first pass. Switching it to something like if (v == 0) blah Seems to be a bit clearer to me.
I can confirm this on .12.1 and .13 on Feisty with 2 different iPods.
Confirmed with 0.12.1 on Gentoo. My previously included patch still applies cleanly and seems to address the problem.
Maybe we can get this bug on the next bug party ;).
I don't have any non-local stuff; can anyone see if it still happens in 0.13.2 or SVN? If so, we may need to update the patch.
Closing this bug report as no further information has been provided. Please feel free to reopen this bug if you can provide the information asked for. Thanks!