Rewrites the internal/library comment blocks to rule 32. Task, milestone,
decision and rule ids are gone; the incidents behind them are restated as
the constraint they left (why a file is deleted before its row, why the
missing mark is a mark, why duplicates block on duration). Counts and
album names from one library are dropped from production comments; test
comments keep the names their fixtures use. The tagReadVersion log keeps
each version's before and after, without the measurements.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
A cross-release group was only ever linked, never merged, so an album that
held the song twice among the releases kept both: Humanz has Saturnz Barz,
Andromeda, We Got the Power and Garage Palace as its FLAC and a YouTube mp3,
each beside the single. The resolver now merges an album's extra copies
into its best (the one that is not a video rip, else ProposeSurvivor:
lossless first) with ReplaceTrack, history and all, then links what is
left as one song.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Lidarr is off, and with it the resolver had stopped merging: it only
merged when Lidarr had said which copies it mapped. Minstrel is now the
only program writing the library, so the rule is about the copies:
- A song held twice on one album: the extra copies merge into the one
whose tags fit best (then lossless, larger, older).
- Across releases or under another title: when every copy but one is a
video rip (held back, or named like one and not marked fine), the rips
merge into the one that is not.
- Clean copies on different releases are linked as one song, as before.
- Anything else waits for the operator.
Gone with Lidarr: release switches and their settle window, the
unmapped-file read, the rip search, the merge guard and its 409/503,
lidarr.Client's release methods, and duplicate_group_members.lidarr_state
(migration 0078). The duplicates page drops the per-copy Lidarr badge
and the blocked-merge notice; past release changes stay in its history.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
MergeInheritSongLink took "linked" to mean song_key <> id, but the copy
whose id became the song's key has no song_id of its own. Removing that
copy dropped the survivor out of the song. It now asks whether another
copy shares the key. The test covers both copies as the one removed, so
it no longer passes or fails on which random id sorts first.
The release-change test counted audit rows other tests left behind
(ResetDB keeps audit_log); it now counts what its own pass adds.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
A single and the album it is on stay two files, since each fulfils its own
release in Lidarr, but they are one song to the listener.
- tracks.song_id links copies; the generated song_key (song_id, else the
track's own id) is what they share (migration 0076).
- The resolver links each cross-release group every pass (idempotent; only
with auto-resolve on) and, when a link is new, shares existing likes across
the song and logs them for sync.
- A like or unlike (web and Subsonic) reaches every copy; each change is
logged and published so clients update every heart.
- The Liked list and its count show the song once; Shuffle and the mix writer
take one copy per song.
- A merge keeps the removed copy's song link; "Not the same song" on the
Across releases tab dismisses the group and undoes the link.
Shared plays ("heard via another copy") are left for a later step.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
bvandeusenandClaude Opus 5.5