Solitary date-style composer tag inexplicably under "M" heading
-
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.
-
@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.
-
@jonas any ideas about this one boss? Would be nice to get it off my desk. Cheers!
-
@Sharky-PI
Can you send me a file that appears incorrectly? -
@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:
-
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 quirkCritical 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 keysTheories 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 bugFiles 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 -
-
@Sharky-PI
What OS is this on, and what locale settings do you have? -
@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.
-
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...
-
Just updated to 1.2.14, no change
-
Yes it is strange, I don't know where M comes from. The divider key is set from the sort text, but the sort text is the same as composer unless composer sort is set.
Hard for me to figure out since I can't reproduce it, but if someone else can reproduce it, here is where it needs to be debugged:
