#1555 - Stop-gap: drop MusicBrainz IDs when artist name and MBID counts differ

[Rouzax]

Summary

Stop-gap mitigation for #1555 (and the earlier #1052, same root cause). Does not close the issue. The structural fix is a separate follow-up.

Slim::Schema::Contributor::add splits the artist-name tag and the MusicBrainz-ID tag independently, then zips them positionally without checking that the lengths match. When they don't, the first MBID gets silently bound to a joined-display name (e.g. "Artist A & Artist B" with 2 MBIDs, or "Artist A ft. Artist B" with 1 name after splitTag but 2 MBIDs). That poisons the contributors row, and any later track whose MBID matches that row inherits the wrong display name.

This patch adds a length-mismatch guard: when the MBID count and the name count don't agree, the MBIDs are dropped for that call and the contributor row is created without an MBID binding. A single INFO log line in the scan.scanner category makes the condition diagnosable.

Scope: stop-gap, not a fix

This is the minimal defensive guard so existing libraries stop getting poisoned during scan. The proper resolution is to read the plural ARTISTS / ALBUMARTISTS Picard tags as the indexing source of truth (using them for contributors rows and indexing while keeping ARTIST / ALBUMARTIST for display). That work is structural and will be a separate PR / RFC. Issue #1555 should remain open until that lands.

Behavior

• Aligned Picard-convention tags (the common case): no change.
• Length-mismatched tags (the bug case): MBIDs dropped, row created under the joined name without an MBID, no cross-track poisoning.
• No schema change, no migration.
• Affects all contributor roles (ARTIST, ALBUMARTIST, TRACKARTIST, COMPOSER, user-defined) since Contributor::add is role-agnostic.

Already-affected libraries

Users whose library already contains a poisoned contributor row need to run wipecache after upgrading for the fix to take effect on existing data. Without that, the existing bad row stays in the DB until its tracks are removed.

Verification

The reproduction zip from the issue (two 2-second silent Opus files) was scanned end-to-end on a clean LMS instance, both before and after this patch. Direct DB inspection of the resulting contributors and contributor_album rows:

	Baseline (no patch)	With patch
Contributor Martin Garrix & Alesso	MBID = 3e1f2ee4-... (Martin Garrix's MBID, POISONED)	MBID = NULL (correct)
Contributor Martin Garrix	MBID = NULL	MBID = 3e1f2ee4-... (correct)
Test Solo Album displayed under	Martin Garrix & Alesso (BUG)	Martin Garrix with correct MBID

The follow-up reproduction in the issue comments (ARTIST = "Armin van Buuren ft. Anne Gudrun" with 2 MBIDs against the ARTIST role) is the same length-mismatch class and is also addressed by this guard.

No automated tests exist for Schema::Contributor, so verification is manual. t/00_smoketest.sh and t/verifyStrings.pl remain green; no strings or schema were touched.

Notes

• No new logging category; reuses scan.scanner already present in this file (used by rescan()).
• No changes to Slim::Music::Info::splitTag or the splitList preference.
• No changes to MBID-first lookup behavior at line 268+; that lookup is correct once row data is no longer poisoned.

[michaelherger]

Looking good to me. Just minor tweaks below. Thanks!

[Rouzax]

Thanks! Both changes done in the updated commit:

• Hoisted $log to the top of Slim/Schema/Contributor.pm next to $prefs, removed the duplicate my $log = logger('scan.scanner'); from inside add() and from rescan().
• Shortened the Changelog entry to the single-line version you suggested.

[michaelherger]

Are you a bot? Or using one to generate all this textual content?

[michaelherger]

Thanks!

The other PR will take a little more time to review, as you can imagine.

[Rouzax]

Are you a bot? Or using one to generate all this textual content?

I'm a human but Running Claude Code to create these fixes 😄, so a bit of both
Was building some tools for myself and ran into these issues

[darrell-k]

I know this is merged, but I have reservations: see https://forums.lyrion.org/forum/user-forums/ripping-encoding-transcoding-tagging/1816764-lms-metadata-scaan-overrides-local-tags?p=1819451#post1819451