5 Commits

Include renames

Author	SHA1	Message	Date
bvandeusenandClaude Opus 5.5	5c19a916ba	feat(library): store each album's MusicBrainz release-group id (M483 #5242) ... albums.mbid is the release id (Picard's musicbrainz_albumid, one edition). Lidarr names albums by release group, so re-acquisition and request completion need that id too (#5241). Migration 0070 adds albums.release_group_mbid (nullable, non-unique index: several releases share a group). The scanner reads musicbrainz_releasegroupid through extractReleaseGroupMBID, writes it on insert and heals it onto existing rows when NULL. tagReadVersion goes to 3 so the next scan fills it for the library already indexed, bound by tag reads (no ffprobe, no decode). Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>	2026-10-07 11:33:26 -04:00
bvandeusenandClaude Opus 4.7	4481874482	fix(server,web/m7-382): handle duplicate-MBID conflicts during backfill ... Forward-fix from running the prior two commits in production. Backfill on a real library exposed two further issues: (1) gofmt -s flagged the column-aligned stubMeta methods in mbids_test.go. Switched to the gofmt-canonical single-space form. (2) Many albums failed to heal with SQLSTATE 23505 (unique constraint albums_mbid_unique). Cause: the operator's library has duplicate album rows in the DB — same MusicBrainz release, split into multiple rows by the pre-MBID scanner because of subtle title or artist disagreements between files. When backfill now correctly extracts the MBID, two rows want to claim the same one and the partial unique index rejects the second. The conflict is correct DB behavior — we shouldn't have two rows with the same MBID — but it's not a write failure to alarm the operator about. Detect 23505 specifically: - downgrade the log line from Warn to Info - track these in a new BackfillMBIDsResult.Duplicates counter (separate from Skipped, which retains its "no MBID in tag" meaning) - leave the duplicate row's mbid NULL; merging duplicates is a separate (future) operator workflow Same handling threaded through the scanner heal path so a regular rescan doesn't generate the noise either. JSON tally + admin UI gain a "Duplicates" line so the operator can see how many duplicate rows their library carries. Follow-up scope (separate task): a duplicate-album merge UX that reparents the duplicate's tracks to the canonical row and deletes the orphaned album row. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>	2026-05-04 21:45:15 -04:00
bvandeusenandClaude Opus 4.7	cc12ab7e96	fix(server/m7-382): strip NUL bytes from MBIDs before persist ... Follow-up to 947f944. With the dhowden/tag/mbz extractor now correctly matching ID3v2 TXXX frames, mbid backfill started rejecting every row with "invalid byte sequence for encoding UTF8: 0x00 (SQLSTATE 22021)". Cause: dhowden's readTextWithDescrFrame (id3v2frames.go:454) — the path that decodes TXXX text — does NOT strip the trailing/embedded NUL bytes that ID3v2.4 uses as frame terminator and multi-value separator. Unlike readTFrame, which does (line 313). So a TXXX:MusicBrainz Album Id of "abc-123\x00" comes back to us verbatim, and Postgres refuses to store NULs in text columns. cleanMBID splits on NUL and returns the first non-empty segment, which also handles the multi-value case (collaboration artist IDs are NUL-separated; Minstrel uses the primary for MBCAA, so first wins). Tests cover the trailing-NUL, multi-value, and all-NUL paths. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>	2026-05-04 21:35:01 -04:00
bvandeusenandClaude Opus 4.7	947f944fe9	fix(server/m7-382): MBID extraction never matched dhowden/tag's Raw() keys ... The hand-rolled extractor in internal/library/mbids.go looked up keys that dhowden/tag never produces, for every supported audio format: Vorbis (FLAC/OGG): dhowden lowercases keys at parse time (vorbis.go:59), we looked up MUSICBRAINZ_ALBUMID. Always missed. ID3v2 (MP3): dhowden stores TXXX frames under bare TXXX/TXXX_N keys with *tag.Comm values; the Picard tag name is on the value's Description field, not part of the key. We looked up TXXX:MusicBrainz Album Id. Always missed. MP4 (M4A): dhowden stores freeform iTunes atoms under their bare sub-name. We looked up ----:com.apple.iTunes:MusicBrainz Album Id. Always missed. Net effect: every album in the m7-380 boot backfill reported processed=N, healed=0, skipped=N. The m7-379 enricher gate then short-circuited NULL on every album, so MBCAA was never queried. Symptom: "all albums skipped" during cover enrichment. The pre-existing unit tests passed because they hand-built Raw() maps with the intended-but-incorrect keys, never round-tripping through dhowden's parser. Replace the hand-rolled extractor with dhowden's own mbz sub-package, which knows the per-format Raw() conventions and uses lowercase canonical keys (mbz.Album, mbz.Artist). Update both call sites to pass the full tag.Metadata instead of just Raw(). Rewrite the test with a stubMeta implementing tag.Metadata, asserting against the actual per-format Raw() shape, plus a regression guard that pins "uppercase Vorbis keys must not match" so the v0 bug can't sneak back. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>	2026-05-04 21:15:51 -04:00
bvandeusenandClaude Sonnet 4.6	ab8fff834a	feat(server/m7-379): extract MusicBrainz IDs from audio tags during scan ... Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>	2026-05-04 19:01:55 -04:00