2 Commits

Include renames

Author	SHA1	Message	Date
bvandeusenandClaude Opus 5.5	8bd48b4302	fix: a merge keeps the song link when the removed copy names the song (M498) ... 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>	2026-10-08 22:53:35 -04:00
bvandeusenandClaude Opus 5.5	5b372f61d7	feat: the same song on several releases counts as one song (M498 #5438) ... 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>	2026-10-08 22:07:55 -04:00