Another potentially useful datum:
All House genre tracks dumped into a playlist, sorted by composer (my 'date added' column): works EXCEPT 2023.01.23, and 2024.10.30, both sort out of order. 2023.01.23 weirdly don't sort next to each other.
unicode characters are normal for the correctly sorted entries,
but also the incorrectly sorted ones, so it looks like it's not a characters issue (I've typed all of these manually so inserting unicode seemed unlikely but just in case)
@jonas potentially useful data point:
µ-Ziq, conceptually but not actually beginning with M, is filed under M, but the Georgian deep house artist below is filed under their first character.
So weird it's fine for you but weird for me though...!
(edit, this is grouped by Artist/Album, but is potentially useful info)
Just updated to 1.2.14, no change
rebooted:
locale
LANG=en_GB.UTF-8
LANGUAGE=en_GB:en
LC_CTYPE="en_GB.UTF-8"
LC_NUMERIC=en_GB.UTF-8
LC_TIME=en_GB.UTF-8
LC_COLLATE="en_GB.UTF-8"
LC_MONETARY=en_GB.UTF-8
LC_MESSAGES="en_GB.UTF-8"
LC_PAPER=en_GB.UTF-8
LC_NAME=en_GB.UTF-8
LC_ADDRESS=en_GB.UTF-8
LC_TELEPHONE=en_GB.UTF-8
LC_MEASUREMENT=en_GB.UTF-8
LC_IDENTIFICATION=en_GB.UTF-8
LC_ALL=
No change to those files. The mystery deepens. This is so weird...
@jonas oh weird.
Ubuntu 25.04, language English UK, formats USA but I'll change that to UK. Currently:
locale
LANG=en_GB.UTF-8
LANGUAGE=en_GB:en
LC_CTYPE="en_GB.UTF-8"
LC_NUMERIC=en_US.UTF-8
LC_TIME=en_US.UTF-8
LC_COLLATE="en_GB.UTF-8"
LC_MONETARY=en_US.UTF-8
LC_MESSAGES="en_GB.UTF-8"
LC_PAPER=en_US.UTF-8
LC_NAME=en_US.UTF-8
LC_ADDRESS=en_US.UTF-8
LC_TELEPHONE=en_US.UTF-8
LC_MEASUREMENT=en_US.UTF-8
LC_IDENTIFICATION=en_US.UTF-8
LC_ALL=
I'll reboot for UK and see if it changes anything.
Some diagnosis attempts from Claude, unsuccessful:
All other dates work correctly, including:
2024.10.31 ✓
2024.10.20 ✓
2024.10.10 ✓
2025.07.30 ✓
2025.09.30 ✓
All other October 2024 dates ✓
What This ISN'T:
Integer division (30 // 10 = 3) - would affect 2024.10.31 too
Simple format swap (YYYY.DD.MM) - would affect 2024.10.31, 2024.03.10
All .30 dates - only 2024.10.30 breaks
All month=10 dates - other October 2024 dates work
Hash collision or mathematical artifact
Hex/binary representation quirk
Critical Finding
The sort key starts with 'M'
The grouping header comes from the first character of the sort key. For 2024.10.30 to appear under 'M', its sort key must start with 'M' (not '2' or '0').
Possible Explanations:
Date parsing creates month name string - Parser detects date → converts to "March ..." (month 3) → sort key = "March..." → first char = 'M'
Specific string replacement - Code replaces "2024.10.30" with month name starting with 'M' (March, May, etc.)
Locale-specific format string - Date formatter outputs "M..." format for this specific date only
Sort tag generation bug - Composer field has special date handling that generates month-based sort keys
Theories That Fit
Month 3 (March) Connection:
30 - 27 = 3 → March
Some wrapping/modulo creating month 3 from day 30
But why doesn't 31 also break?
Most Likely:
Specific pattern/regex matching *.10.30 or 2024.10.30 that triggers date-to-month-name conversion, outputting something like "March 2024" or "Mar..." as the sort key.
What We Can't Check (Need Codebase Access)
SortText generation for composer field - does it attempt date parsing?
Date-to-string conversion - any code converting dates to month names for sorting?
Sort key logic - what generates the sortable string from composer tag?
Hardcoded patterns - search for "10.30", "2024.10.30", or month name generation
Article/prefix stripping - any "A"/"The" logic that might affect numbers?
Sort tags feature (v1.2.12) - recent addition, potential new bug
Files to Examine
src/collection/collectionmodel.cpp - sorting/grouping/header logic
src/core/song.cpp - SortText generation for composer field
Date parsing utilities
Any locale/format conversion for sorting
Recent commits related to sort tags
@jonas https://drive.google.com/drive/folders/1W4HT_7AmekeCfh6rdav01jfd3Bhx_Ij0?usp=sharing copied them here but I'm >99% sure it's not the files: I personally tagged them with that specific composer string and only that string seems to cause them to be filed under M.
I just did the same for a random song which wasn't tagged with composed, and it then becomes populated under M like the others:
@jonas any ideas about this one boss? Would be nice to get it off my desk. Cheers!
@jonas any thoughts about this one chap? Super weird, I can't conceive what the issue might be, unless "2024.10.30" somehow compiles to the same hex code as M, or some other completely unexpected, arcane, but technically logical reason.
@rik Oh interesting. That definitely looks like it should display. Sorry mate, not sure then 
@ruinspc IIRC you fix this on a per-tracks basis by unclicking "compilation" in the track's properties. Or similar option.
@rlkeeney very unlikely mate, but: any chance it's a hardware issue, and it's randomly finding segfaults on the disk? Worth running a chkdisk on it just to rule it out?
@rik I ended up using Claude to delete all the publisher art and waveform images that beatport adds ("a brightly colored fish" is the art tag for those for some reason).
It would be nice if Strawberry defaulted to Cover Art Front though
More sleuthing has uncovered something. Puddletag shows various files with Playcounts with 2 values e.g. 0\0, 0\258, up to 0\65335.
I tried to delete those screwy counts in puddletag by overwriting them with 0 but it doesn't seem to have taken. Or they've regenerated.
Checking in kid3 it turns out that one of those files, with 0\258 has
FMPS_PLAYCOUNT=0
FMPS_Playcount=258.
If I listen to it once in strawberry:
FMPS_PLAYCOUNT=0,
FMPS_Playcount=259.
So strawberry increments FMPS_Playcount but not FMPS_PLAYCOUNT.
I wonder what the official/correct tag name is?
https://www.exiftool.org/TagNames/ID3.html this says it's "PCNT" for id3 v2.4
According to https://github.com/strawberrymusicplayer/strawberry/issues/1074 , FMPS_Playcount (Strawberry spelling) is CORRECT, so logically something else has been using FMPS_PLAYCOUNT.
But why do they (second entry, FMPS_Playcount) go up to 65335?
And does overwriting them with 0 in puddletag not work because it's displaying 2 variants of the same tag?
In puddletag I can't create separate columns for the 2 spellings because it automatically uppercases them but displays both.
non-strawberry solution: if your playlists are in a central location (e.g. /Music/playlists/) then you could 'search within files / search file contents' using whatever OS-default search tool you have handy?
Now if you were feeling INCREDIBLY saucy, you could setup a cron job to
Hi @jonas , is there a reason this wasn't added originally?
Potentially would massively inflate the library if all lyrics data were imported there?
It would be great to have this... any chance you could talk me though the blockers to implementing?
Cheers!
@nainggolouille I believe it happens automatically in the background
(Just in case you didn't know) you can change the sort order with the spanner icon.
Another low tech way to achieve this is load all of your tracks into a playlist and sort it how you like. Which you can do multiple times.
I enter "date acquired" as YYYY.MM.DD in Composer.
I recently noticed that 2 songs with composer 2024.10.30 are grouped under heading "M" instead of "0-9" like the others.
All are characters manually entered, and I've tried overwriting them with a manually-typed entry - no change.
If I change them to 2024.10.29, stays under M.
2024.10.22: M
2024.10.21: other files already exist with this value, correctly grouped in order under 0-9. When I change the 2 'offending' files to this date, they also get stored in the right place.
If I change them back to 2024.10.30: it goes back under M.
Through years of mostly unsuccessfully migrating across music players, my play counts have generally been reset each time, sadly.
Happily, strawberry saves these to the ID3s, which is great going forward.
However I've noticed that some of my files (about 1990 of 43878 tracks) have play counts increasing from the twenties, to hundreds, thousands, and lots of tens of thousands, 5 digits, specifically with blocks at
10496
16896 (loads of these)
25856
Max = 65335
Then I have two, one with 6384640 & one with 6881400.
Whole albums typically have the same playcount.
I'm not blaming strawberry for this, just wondering if there's any underlying structure/logic which could be extracted.
Ideally some simple mathematical conversion to play count. But I'm not holding my breath!
Any ideas, genius, wisdom, etc, appreciated.
Cheers!