7 Commits

Include renames

Author	SHA1	Message	Date
bvandeusenandClaude Opus 5.5	3a482bd715	fix: AcoustID decides any one-album mismatch the lengths cannot, not only copies each cut to its slot (#6169) ... The first pass on the operator's library held 16 groups. In several, every copy's own lookup names one recording (Wombats Record Shop/Tormentor, Alchemist (2)/Prelude, Monday Chill 8/9, 404sessions), but one copy sits 3-10s from its slot, so the every-copy-fits precondition kept AcoustID out. Now: copies whose lookups all agree are that recording, whatever their fingerprints read; copies of the same audio are asked about as before; and the track list places the recording in one copy's slot, or none. Copies filed as one song are not settled here. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>	2026-10-20 10:52:42 -04:00
bvandeusenandClaude Opus 5.5	18d31e9cdd	feat: one recording cut to several songs' lengths is named by AcoustID; the copy in its slot stays, the rest go, and the release is set aside (#6169) ... Savant's Mortals held one recording as 16 of its 50 tracks, each trimmed to its own slot's MusicBrainz length, so the lengths could not say which slot was its own and every group waited for the operator. When a one-album mismatch is the same audio (identical, or fingerprints within 0.02) and every copy fits its own slot, the resolver asks what the recording is: the copies' own AcoustID lookups, or a fresh lookup of one copy (five a pass). The track list names each slot's recording; the copy in that slot is kept and the others removed, or every copy when the recording is in none of their slots or AcoustID knows none. AcoustID unreachable or answers in several copies' slots: the group waits. Whenever wrong-slot copies are removed, the download the files were imported from is set aside, so the album fetched again is not the same files. Albums imported before Minstrel downloaded anything have none. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>	2026-10-20 10:33:55 -04:00
bvandeusenandClaude Opus 5.5	8daa3d07b5	fix: a slot emptied of another song's file drops that file's recording MBID, so missing-pair folding cannot fold it into the copy kept (M498) ... On 2026-10-20 twelve of the 24 slots the resolver emptied were folded by MBID into the kept copy, so their albums were never wanted back. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>	2026-10-20 09:39:17 -04:00
bvandeusenandClaude Opus 5.5	a3d9effca3	feat: when no slot an album gives one recording is its own, every copy is removed and the album fetched again (M498) ... Shnabubula's whole album, one 45-minute file, was filed as both Fading Light and Looking for Answers. Neither slot fits, so wrongSlots had nothing to keep and held the group. Every copy now goes when each is clearly another song's; a copy near its slot still holds the group. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>	2026-10-20 09:21:43 -04:00
bvandeusenandClaude Opus 5.5	c8e855ae4a	feat: the duplicate resolver fetches a missing album track list from MusicBrainz to decide a wrong slot, five albums a pass (M498) ... 20 of the 34 groups left for review had no cached track list for their album: the catalogue only reads one when the wanted list or the importer needs it. The resolver now asks catalogue.RefreshReleaseGroup for an album it must decide and the catalogue has never read, through the shared MusicBrainz pacer, at most five a pass (hourly). An unreachable MusicBrainz stops the pass's fetching; a group read and found empty is not asked about again. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>	2026-10-20 09:02:53 -04:00
bvandeusenandClaude Opus 5.5	c5868c00cc	feat: a version named after a dash counts as a version, and a song held twice beside a wrong slot no longer blocks it (M498) ... - songKey drops a dashed version suffix (" - Instrumental Version", " - Radio Edit", live, remix, mix, acoustic, demo, reprise, rework, VIP), so Andora's "Goodbye Yesterday - Instrumental Version" is distinct, not a wrong slot. - wrongSlots accepts several fitting copies when they share one title (Killjoy twice beside Dreamland): the other slot's copy is removed, and the doubled song is left for the next sweep to find as a pair the resolver merges. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>	2026-10-20 06:24:47 -04:00
bvandeusenandClaude Opus 5.5	0f58ebcd6c	feat: duplicates settle themselves: retitled copies across releases link, alike versions on one album are dismissed, and a file in another song's slot is removed so the album is fetched again (M498 #6159-#6162) ... The operator's library had 536 groups waiting for review, 2026-10-19. A sample showed most were one recording under two titles on two releases. - The headline and the Duplicates count leave out cross-release groups, which the resolver keeps and links: the headline read 3,479 when 536 needed review. - Any group spanning albums is cross_release and is linked as one song, whatever its titles say. Nothing is deleted. - One album, two versions named as such ("Lovesick (Instrumental)") and not byte-identical: a new class, distinct, dismissed by the resolver. - One album, one recording under different song titles (mismatch): the album's cached MusicBrainz track list decides. When exactly one slot's song is as long as the file and every other slot's song is clearly not, the other copies are removed and their tracks marked missing, so the reacquisition sweeper wants the album back. Otherwise the group stays for review. - The duplicates_found notice moves from the sweep to the resolver: it names only groups a pass first left for review. - Resolved automatically lists dismissals and wrong-slot removals beside merges. Migration 0094 adds 'distinct' to the class CHECK (rule 36). Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>	2026-10-19 23:22:38 -04:00