Sorting by time does not work properly

[Adam Olsen]

Sorting by tracklength causes wrong result (see attached image).

This ticket was migrated from the old trac: re #137

[Mathias Brodala (mathbr)]

I can’t reproduce this no matter what I try. Sorting by track length works fine all the time.

[Mathias Brodala (mathbr)]

Marking as fixed as long as no one else confirms this issue.

[Dan O'Reilly (oreilldf)]

I can confirm that it doesn't always sort correctly. It sorts tracks under a minute, follow by tracks 10 minutes or over, followed by tracks greater than a minute but less than 10. See the attached image. The problem is it's sorting track length as a string, so 10:35 comes before 9:35, since it just checks the first character. I wrote a quick patch that solves the problem, although there might be a more elegant solution.

[Dan O'Reilly (oreilldf)]

Here's the patch. I added a function that converts track.length to seconds, then sorts using that.

[Adam Olsen (arolsen)]

Patch committed in r1363

[Dan O'Reilly (oreilldf)]

I took a look at what was getting stored in each media.Track object and realized that the length in seconds is already getting stored, so a little CPU time could be saved using the already stored value as opposed to calculating it again for every track during a sort. Patch for it is attached.

[Johannes Sasongko (sjohannes)]

Would be nice for duration and bitrate to use a special int with fancy __str__, but for now this should be alright.

I'll push the fix once Launchpad finishes maintenance.