Replace swap with separate display_artist storage

[Rouzax]

Summary

Replaces the tag-swap mechanism with dedicated display_artist columns on albums and tracks. Stores ALBUMARTIST/ARTIST tag values directly as display strings. When the opt-in preference is enabled, ALBUMARTISTS/ARTISTS plural tags are used as the sole contributor source.

Changes

• Schema: display_artist columns on albums and tracks (schema_27_up.sql). Replaces albums.label placeholder.
• Scanner: Captures display strings before _preCheckAttributes, stores in columns. Both create and update paths handled (fixes the rescan bug).
• Queries: COALESCE(display_artist, contributors.name) for the a tag artist field. display_artist returned alongside existing fields. UTF-8 decode added. No breaking API changes.
• Preference: usePluralArtistTags in Settings > Behavior. Off by default. When on, plural tags replace singular for contributor creation.
• Search: display_artist added to fulltext index.
• Cleanup: Removes swap blocks, albums.label usage, commented-out contributor_display tables, debug logError.

Why replace the swap

• Rescan path skipped the swap (only in _newTrack, not update path)
• Scenario 3 data loss when ARTISTS has fewer entries than ARTIST
• Display string detection heuristic proved unsolvable across languages

Flat columns match the Navidrome/OpenSubsonic model where displayArtist is a simple string field.

Testing

Verified with 52 automated tests covering fresh install, schema upgrade (26 to 27), album rescan after retagging, preference toggle, regression on 18 existing fixture patterns, and API contract validation.

What is kept from your branch

• display_artist field name in the API
• show_artist_list popup concept (Material PR to follow)
• The contributor_album structure

[darrell-k]

I've implemented the full 3nf schema changes in the branch, otherwise it's confusing. Would you mind recreating PRs for the functional changes with that as the base?

[Rouzax]

Thanks for implementing the schema. I will look into rebasing, but just want to flag that it is not a straightforward find-and-replace. Our changes store flat strings directly into columns. Your schema stores integer IDs that reference the contributor_display table, which means every place that captures or stores a display string needs the lookup/insert/get-ID flow. The rescan fix, preference gate, fallback, and track-level population all need to work with IDs instead of strings. I will work through it but it may take a bit.

[darrell-k]

In that case maybe it is best if you wait until I implement trackartist and n&c scanning according to my design. It won't be today.

[Rouzax]

In that case maybe it is best if you wait until I implement trackartist and n&c scanning according to my design. It won't be today.

I said I needed to look at it in more detail, not that it was not possible 😉

[Rouzax]

Superseded by #21 which ports these changes onto your 3NF contributor_display schema.