| View previous topic :: View next topic |
| Author |
Message |
KamikazeMicrowave
n00b
Joined: 20 Jan 2006
Posts: 71
|
 Posted: Tue May 09, 2006 1:10 am Post subject: Amarok playlist sorting |
 |
|
| Is there a way to get amarok to sort a playlist by Artist THEN by the Song titles of that artist? I could do this on Winamp. Any ideas? |
|
| Back to top |
|
 |
KamikazeMicrowave
n00b
Joined: 20 Jan 2006
Posts: 71
|
| Posted: Wed May 10, 2006 5:34 am Post subject: |
|
|
| anyone? |
|
| Back to top |
|
|
BitJam
Advocate
Joined: 12 Aug 2003
Posts: 2513
Location: Silver City, NM
|
| Posted: Wed May 10, 2006 7:26 am Post subject: |
|
|
Here is a link to a multi-column sort patch for the 1.3 branch of amaroK.
I bet it could be applied to the 1.4 branch too (perhaps with some small variations). |
|
| Back to top |
|
|
BitJam
Advocate
Joined: 12 Aug 2003
Posts: 2513
Location: Silver City, NM
|
| Posted: Wed May 10, 2006 7:24 pm Post subject: |
|
|
I manually applied the patch to amarok-1.4_beta3-r2 and it seems to work like a champ. To sort by artist then title just click the "Title" header then the "Artist" header. To get the old behavior, click the "Track" header first then click whichever header you want to sort by.
I can post a modified ebuild and a patch file if you want to try this yourself. Let me know which version of amaroK you are using because the patches are a little bit different (and so are the ebuilds). |
|
| Back to top |
|
|
markey
n00b
Joined: 12 Sep 2005
Posts: 32
|
| Posted: Wed May 10, 2006 7:48 pm Post subject: |
|
|
We've had this patch in amaroK for a while, but ultimately removed it for performance reasons. Certain playlist operations became dog slow, which just wasn't acceptable.
But if you don't use giant playlists, hey, this patch is probably fine for you.
_________________
Mark Kretschmann -- Amarok developer |
|
| Back to top |
|
|
BitJam
Advocate
Joined: 12 Aug 2003
Posts: 2513
Location: Silver City, NM
|
| Posted: Wed May 10, 2006 9:04 pm Post subject: |
|
|
| markey wrote: | | We've had this patch in amaroK for a while, but ultimately removed it for performance reasons. Certain playlist operations became dog slow, which just wasn't acceptable. |
I'm using the Stefan Siegel patch which should not significantly slow things down. I would be very surprised if there was any noticeable speed difference in the 1.3 branch.
The 1.4 branch replaces QString::localeAwareCompare with a "cmp" macro. If the "cmp" macro does speed things up it could be used inside of Stefan Seigel's patch. But certainly the Stefan Seigel patch in the 1.4 branch should be no slower than the current sort in the 1.3 branch.
It is interesting to note that the new "cmp" macro code starts with: | Code: | | //damn C++ and its lack of operator<=> |
which indicates that the person who added this code was unaware of QString::localeAwareCompare, which should probably be reinstated since it should work for non-ASCII strings while it is very doubtful that the "<" operator used in the "cmp" macro will always do the right thing despite the fact that it works for simple ASCII strings.
One thing I noticed is that rightJustify() is used inside the compare() method in order to correctly sort numeric fields. This could slow things down since the operation is performed O(n log n) times when it only needs to be done n times (but this is independent of the Stefan Seigel patch). Ideally the rightJustify() could be done on all fields that need it when items are added to the playlist. If this causes undesirable side effects, then at the cost of more memory, rightJustified fields could be added that would be used for sorting. If the extra memory is a problem then a "Schwartzian Transform" could be used which creates the extra fields temporarily for the sort then removes them when the sort is completed.
Bottom line is: the Stefan Seigel patch is minimally invasive and should not slow things down. I think it should be considered for inclusion of the next release. I can supply you with a modified 1.4_beta3-r2 ebuild and a patch file so you can try it yourself. I added a "multicolsort" use flag to make it easier to switch this feature off and on. I can also run some benchmarks on my system (1.6 GHz P4) if that would help you feel more comfortable with considering this patch.
Edit: I just tested sorting a playlist with 1433 tracks. On my system each sort takes about 4 to 6 seconds. This is not stellar performance but quite acceptable (to me). When I go up to 1999 tracks the time goes up to 8 or 9 seconds. Since it takes about 2 or 3 seconds just to add some more tracks to these longer playlists, the sort times do not seem unreasonable. I also noticed that even with these longer playlists the "Track" fields sorts faster than "Artist" or "Title" which indicates that the rightJustify() code does not hurt the speed as much as simply longer strings, so no extra effort should be expended to get rid of it unless some other problem with it pops up. |
|
| Back to top |
|
|
|
Multimedia
