12 Commits

Include renames

Author	SHA1	Message	Date
bvandeusenandClaude Opus 5.5	ca57133c8a	fix: a release group whose title names a live, remix or demo version is wanted only when the profile allows that version (M502 #5573) ... MusicBrainz types My Chemical Romance's "Common People (Recorded For BBC Radio 1)" as a plain Single, so a studio-only follow wanted it. Passes now reads the title's qualifier (brackets, or after a dash) for the version it names and treats it as a secondary type; a version no type names, an acoustic or instrumental one, no profile passes. The follow check takes off the list an open follow want the rule now refuses. Judge counts bbc, sessions and unplugged as live. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>	2026-10-10 18:39:35 -04:00
bvandeusenandClaude Opus 5.5	7ef1fca90c	fix: an album holding every track of an edition, and more besides, is that release group (M502 #5569) ... Savant's "Void" folder holds all 23 tracks of the VOID (DLC) edition plus 20 more, and was refused at 23 of 43. A whole edition of three or more tracks now matches whatever else the folder holds; singles and two-track releases still need most of the album's tracks, since many albums hold their songs. Matcher version 4 retries the refusals. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>	2026-10-10 18:14:56 -04:00
bvandeusenandClaude Opus 5.5	1936fe77c6	fix: the matcher-retry test stamps the listing's cutoff after its albums exist, as a listing done before them would not see them (M502 #5569) ... Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>	2026-10-10 17:51:42 -04:00
bvandeusenandClaude Opus 5.5	bf409d5f3f	fix: a second copy of a track counts once, joining words don't part two titles, and a newer matcher retries an older one's refusals (M502 #5569) ... The second run's refusals were mostly albums holding a track twice (a two-track single with three files), which no edition can pair, and release names that differ only in "+" against "/". Tracks are now read once per disc, number and title, and "and", "&" and "+" count for nothing when titles are compared; an edition's own title also counts as the album's name. library_album_matches records which matcher version decided each album. Refusals by an older version are matched again, even after the listing is done, so an improvement reaches them without a migration. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>	2026-10-10 17:44:06 -04:00
bvandeusenandClaude Opus 5.5	80d2fdc3ab	fix: under the album's own name, matching track titles are enough to match it; a refusal says which track differed and how (M502 #5569) ... The first run on the library refused singles whose one track has the album's title ("0 of 1 agree") and near-complete albums (11 of 14), because every track's length had to fit as well. Lengths now only decide between groups whose names merely overlap. The reason for a refusal names the first track that differed, with both titles and lengths, so what is left can be judged. Migration 0087 clears the refusals so those albums are matched again. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>	2026-10-10 17:29:42 -04:00
bvandeusenandClaude Opus 5.5	b887ab759b	fix: every library album is matched to MusicBrainz before it is listed, by its tags, its artist's discography or a search, and checked against its tracks (M502 #5569) ... The one-time listing took only albums whose tags already named their release group and artist, and left 340 off the list. The rest are now matched: the release their tags name, else the artist's release groups called what the album is called, else a MusicBrainz search by artist and title. A group found by name is taken only when its tracks agree with the album's (by disc and number, then title; length and title, or recording), so a partial copy still matches and a same-titled other album does not. library_album_matches records each album the listing decided, listed or unmatched with why, so an album taken off the list is never re-listed. The albums no match was found for are named on the Held tab. Album rows with no tracks are no longer counted. The length and title checks move from the importer to release, shared by both. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>	2026-10-10 17:16:05 -04:00
bvandeusenandClaude Opus 5.5	2c677b3184	feat: the library's albums go on the wanted list as held, once; after that the list is the truth (M502 #5567) ... A one-time job in the wanted worker lists every album in the library as a held want, one per release group, with a record that it happened (acquisition_settings.library_listed_at). Albums whose tags name only a release are named on MusicBrainz first, 120 a pass; what nothing names is counted and shown on the Held tab. Re-acquisition now wants back only albums on the list. Taking a held album off the list leaves its files, and it is never fetched back; albums put in the library folder by hand afterwards are not added. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>	2026-10-10 16:13:46 -04:00
bvandeusenandClaude Opus 5.5	ebbc49b902	feat: import with verification, and a Wanted view of its own (M502 #5522) ... A finished download is checked against MusicBrainz before anything is filed: the files are paired with an edition's tracks by position or path, and AcoustID, tag ids, lengths and titles say whether it is the album. What is the album is copied into the library as Artist/Album (Year)/Artist - Album - NN - Title, tagged with Picard's MusicBrainz ids, and scanned; the download keeps seeding. What is not is refused: set aside, removed from the client, and the album searched for again. A download the check cannot settle waits for a person, who imports it anyway or refuses it. Tracks the library already holds are skipped. The wanted list leaves Admin for a top-level Wanted view, admin-only and web-only, with tabs for Wanted, Activity (downloads and their imports, the ones needing a person first), Missing files, Held, Following (with the release-type profiles, moved off Integrations) and Blocked. The search settings gain "File new music into" when the library has several folders. The search pass logs why each failed search failed. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>	2026-10-10 10:36:21 -04:00
bvandeusenandClaude Opus 5.5	77081f1cef	fix: the search schedule logs its state when it changes, so an idle pass says why (M502 #5521) ... Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>	2026-10-10 09:30:26 -04:00
bvandeusenandClaude Opus 5.5	7f1fe57935	fix: the search test reads the last pass as JSON, since jsonb respaces it (M502 #5521) ... Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>	2026-10-10 09:02:18 -04:00
bvandeusenandClaude Opus 5.5	89b3b44779	feat: search and grab — music release names, a quality ladder, a paced search schedule and one live grab per want (M502 #5521) ... - internal/release: reads a release name (format, bitrate, bit depth and sample rate, source, year, video, discography) and judges it against the album wanted: the artist and title must be in it; video rips, discographies, other versions (drumless, instrumental, karaoke, remix, live unless the album is live…) and singles or EPs for an album are refused. Quality tiers on Lidarr's ladder; a .torrent's file list is read for format, video files and a track count short of the album. - internal/acquire: fan-out across every search source with a narrowed search kept, a process-wide pacer per source, every candidate judged and kept with its reasons, and the grab: one live grab per want, tie-broken (a person's grab beats the schedule's; a better release replaces a worse one unless it is nearly done). Each download lands in its own folder under the client's downloads folder. - internal/wanted: the search schedule, every ten minutes, never-searched first, then requests, missing files and followed artists, taking the best release when auto-grab is on (the default). - Migration 0082: acquisition_settings (auto-grab, interval, allowed qualities seeded from Lidarr's "Any"), want search columns, want_candidates, grabs, release_blocks. - Web: the Wanted page shows each want's last search, a Search button and every release found with its verdict (Grab, Grab anyway, Never this one, Allow again). Integrations gains "Searching and grabbing". Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>	2026-10-10 08:56:47 -04:00
bvandeusenandClaude Opus 5.5	04515a977c	feat: a wanted list — follow artists on release-type profiles; requests and re-acquisition become wants (M502 #5520) ... Minstrel keeps its own list of what it is to get, keyed by MusicBrainz release group. A want comes from an approved request, a new release by a followed artist, or an album whose files went missing, and is held once the library has a full edition of it. - Migration 0081: release_type_profiles (Standard seeded: Album, EP, Single, studio only), follows, follow_seen_groups and wants. lidarr_requests becomes requests with plain *_mbid columns; approved album and track requests move onto the wanted list, approved artist requests become follows, and the library's album artists start out followed. missing_reacquisitions and the retry settings go. - internal/wanted: follows are checked against MusicBrainz discographies daily. The first check sets a baseline, and only releases after it are wanted unless the follow asked for what already exists. Profiles filter by primary and secondary type, so live recordings stay out unless a profile ticks Live. - internal/requests (was lidarrrequests): approving puts the request on the wanted list, and an artist request can be approved on a chosen profile. A request completes when its want is held. - The re-acquisition sweeper wants a missing album back instead of asking Lidarr; searching for it is the search schedule's (#5521). - Web: an admin Wanted page (Wanted, Missing files, Held, Following), a follow control on artist pages, a release-type profiles card on Integrations, "Approve on a profile" on Requests, and want state on Missing files. The artist detail API returns the artist's MBID. - Android: the request body sends artist_mbid, album_mbid and track_mbid. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>	2026-10-10 00:46:22 -04:00