-
Bug
-
Resolution: Fixed
-
High
-
2.12.1
-
None
-
Windows 11
Picard 2.12.1
I noticed a sorting error in Picard by artist after Scan.
These are files with artists starting with a digit or number.
They should be at the top of the list.
1 follows the letter C
2, 3, 4 follows the letter D
5 follows the letter E
9 follows the letter G
first and last screen is OK
- is duplicated by
-
-
- Closed
-
- is related to
-
-
- Closed
-
[PICARD-2953] Windows: Incorrect sort order in list views and search result
Reported to Qt at https://bugreports.qt.io/browse/QTBUG-128170
There is a whole bunch of QCollatorSortKey issues reported for Qt on Windows (which might or might not be related to a single root cause):
- https://bugreports.qt.io/browse/QTBUG-112981
- https://bugreports.qt.io/browse/QTBUG-108756
- https://bugreports.qt.io/browse/QTBUG-88704
This really is a bummer. It means we are back to finding a working way to handle locale aware sorting. Going back to strxfrm is not really an option.
One work around would be to always use numeric mode. Also QCollator.compare(s1, s2) gives the expected results and as opposed to QCollatorsortKey(s1) < QCollatorsortKey(s2). But looking at how we use the sort keys there is no simple way to switch this over to the compare function. Python's sort functions switched from having comparator functions to functions returning a sortable value. And we also use it for sorting values inside tables by Qt, where we also need to provide a sortable value of some sort.
Maybe the tables could be handled differently, need to investigate. Likely Qt itself would already do locale aware sorting. We only need to handle the numeric sorting modes.
I can reproduce on Windows, on other OS it is fine. On Windows it sorts like A, 0, B, C, 1, D, 2, 3, 4, E, 5, F, 6, G, 7, 8, 9, H, I, ....
The sorting is only broken if we use strict alphabetic sorting and not natural / numeric sorting (numeric sorting is when numbers in the string are detected ans sorted accordingly, so "Track 10" comes after "Track 2", and not before as in strict alphabetical character by character sorting). Numeric sorting is slower and only enabled for specific columns, such as track or album title. That's why you only experienced it with artist names and not the titles, but it affects other columns just the same unless they use the numeric sorting.
The issue got introduced with the changes done to PICARD-2914 . At this point we are unlikely to revert these changes, as fixing the crashes has priority. But we need to find some solution to the sorting.
One work around would be to use numeric sorting for all columns. But maybe we find some other way to fix the issue.
Cherry picked for the 2.x branch in https://github.com/metabrainz/picard/commit/3090c1ed0f811aa29a47fa83595d1ffee9175ad2