Symptom
A track whose ARTIST tag joins contributors with commas is linked to a single phantom artist named after the whole string, so clicking the artist from the track goes to an empty page instead of the real artist — even when that real artist already exists and is fully enriched.
Real example from a library:
| Where |
Shows |
| Album page → album artist |
Tibeauthetraveler — real artist, photo, 755 fans, similar artists |
| Track row → ARTIST column |
Tibeauthetraveler, Nogymx, Osaki — phantom, letter avatar, no metadata |
Clicking the artist from the player bar or the track row lands on the phantom. The three contributors are not individually clickable, and the phantom also pollutes the artist list.
Why it happens
The file carries two different tags:
ALBUMARTIST = TibeauthetravelerARTIST = Tibeauthetraveler, Nogymx, Osaki
The scanner handles them separately. The album path resolves Tibeauthetraveler and links the album to the real, enrichable artist row. The track path runs the raw ARTIST value through split_artist_name, which honours only "; " as a separator — so the whole comma-joined string becomes one artist row, and that is what track_artist points at.
This is deliberate, documented behaviour, not a regression: splitting on ", " was removed because a comma can be part of the name itself (Tyler, The Creator, Earth, Wind & Fire, Crosby, Stills, Nash & Young), and the old comma split silently fragmented those into several bogus artists. The documented remedy is to re-tag with "; ".
What this report adds is that the current trade-off has a worse failure mode than assumed: it doesn't merely fail to split, it strands the track on a dead-end entity while the correct artist row already exists next to it.
Options
A. Opt-in "also split artists on comma" setting (Library settings, default off)
Fixes a comma-joined library in bulk on the next scan. The safe default is preserved, so Tyler, The Creator users are unaffected unless they opt in. Open question: apply on next scan only, or also re-normalise track_artist for tracks already in the database?
B. "Split this artist" action on the artist page (via Edit info)
User-driven, so no guessing. Re-links the track to the individual artists, reusing existing rows where they match — in the example above the track would immediately point at the already-enriched Tibeauthetraveler. Fixes the library without re-tagging any files.
C. Status quo — re-tag with "; ". Works today, but doesn't scale to a library that is massively comma-joined.
A and B are complementary: A solves it library-wide, B handles one-off cases without changing the global default.
Notes
- Whatever is chosen must not re-introduce the fragmentation that removing the comma split fixed — the safe default has to stay the default.
- Worth checking how the phantom rows should be cleaned up afterwards (an artist row with no remaining
track_artist links).
Symptom
A track whose
ARTISTtag joins contributors with commas is linked to a single phantom artist named after the whole string, so clicking the artist from the track goes to an empty page instead of the real artist — even when that real artist already exists and is fully enriched.Real example from a library:
Clicking the artist from the player bar or the track row lands on the phantom. The three contributors are not individually clickable, and the phantom also pollutes the artist list.
Why it happens
The file carries two different tags:
ALBUMARTIST=TibeauthetravelerARTIST=Tibeauthetraveler, Nogymx, OsakiThe scanner handles them separately. The album path resolves Tibeauthetraveler and links the album to the real, enrichable artist row. The track path runs the raw
ARTISTvalue throughsplit_artist_name, which honours only"; "as a separator — so the whole comma-joined string becomes one artist row, and that is whattrack_artistpoints at.This is deliberate, documented behaviour, not a regression: splitting on
", "was removed because a comma can be part of the name itself (Tyler, The Creator,Earth, Wind & Fire,Crosby, Stills, Nash & Young), and the old comma split silently fragmented those into several bogus artists. The documented remedy is to re-tag with"; ".What this report adds is that the current trade-off has a worse failure mode than assumed: it doesn't merely fail to split, it strands the track on a dead-end entity while the correct artist row already exists next to it.
Options
A. Opt-in "also split artists on comma" setting (Library settings, default off)
Fixes a comma-joined library in bulk on the next scan. The safe default is preserved, so
Tyler, The Creatorusers are unaffected unless they opt in. Open question: apply on next scan only, or also re-normalisetrack_artistfor tracks already in the database?B. "Split this artist" action on the artist page (via Edit info)
User-driven, so no guessing. Re-links the track to the individual artists, reusing existing rows where they match — in the example above the track would immediately point at the already-enriched Tibeauthetraveler. Fixes the library without re-tagging any files.
C. Status quo — re-tag with
"; ". Works today, but doesn't scale to a library that is massively comma-joined.A and B are complementary: A solves it library-wide, B handles one-off cases without changing the global default.
Notes
track_artistlinks).