9 Commits

Include renames

Author	SHA1	Message	Date
bvandeusenandClaude Opus 5.5	a8a2d20307	feat: stored credentials are sealed at rest, so a copy of the database alone reveals none of them (#6767) ... Minstrel keeps credentials it has to read back: indexer, Prowlarr and download-client keys and passwords, the AcoustID key, cover-art and tag provider keys, the SMTP password, and each user's ListenBrainz token and Subsonic password. They were stored in the clear; they are now sealed with AES-256-GCM under a per-column HKDF key derived from the stream secret, each value bound to its row. - internal/secret: Seal/Open/Reveal, and Columns, the one list of sealed columns (a backup will leave them out). Install takes the master key at startup; SealStored seals any value still in the clear, so an existing database is brought over in place on the first boot. - Every write seals and every read opens: acquire (one read path, getService / usableServices), acoustid settings, SMTP, ListenBrainz, Subsonic auth and password generation, cover-art and tag provider settings. - A value that does not open (the stream secret changed) is logged and reads as unset, to be entered again in Settings. docs/security.md says so. - Tests: secret unit tests (wrong owner/purpose/key, malformed, no key), a SealStored integration test over all eight columns plus a schema check that each listed column exists, and the existing tests now assert sealed storage. dbtest installs a test key for integration tests. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>	2026-11-02 13:23:19 -05:00
bvandeusenandClaude Opus 5.5	08a2c06b85	docs: api comments say what the endpoints do, not how they came to be (#6277) ... Rewrites the internal/api comment blocks to rule 32: task, milestone and rule ids gone, the stories behind them restated as the constraint they left, stale references corrected (the stream secret is wired from config, the timezone handler already refreshes the scheduler, the Android app is the native client, the design docs cited are not in the repo). Also rewraps comment lines over 80 columns left by the earlier batches. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>	2026-10-23 12:23:58 -04:00
bvandeusenandClaude Opus 5.5	d191a28217	docs: server comments say what the code does, not how it came to be (#6277) ... Comment blocks in cmd/minstrel and 30 smaller internal packages, rewritten to rule 32's standard with each citation read in context: task, milestone and rule ids go, and so do the stories they were attached to ("used to", "Before #N", measurements from one install, quotes, pointers to Fabled Librarian's records and to docs/superpowers files that are not in the repo). Where a story wrapped a real constraint, the constraint stays as a present-tense fact. Comments that had gone stale are corrected: - taste.Config: the tuned values are overlaid by internal/recsettings; it is no longer "a later follow-up". - StorageConfig: the data dir holds art, caches and the stream secret, not only playlist covers. - the Subsonic album list and getUser comments describe what they do today rather than a milestone that would change it. Checked: the non-comment token stream of every changed file matches HEAD, and gofmt -l is empty. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>	2026-10-23 12:15:05 -04:00
bvandeusenandClaude Opus 5.5	484a81f779	fix: a release its download client will not let Minstrel follow is held back, not taken every pass (#6176) ... The Black Keys' Ohio Players was grabbed 40 times in a day. FabledExchange already held the torrent under another category from before Minstrel took the downloads over: the add answered "duplicate", which counted as added, and Exchange's listing, filtered to Minstrel's category, never showed it. Half an hour later the grab ended gone, and the next pass took it again. - A duplicate add that the client does not list for Minstrel is not a grab: the release is held back for a day with the client's own reason (already downloading X (category)), and the search moves on. Forced, it is refused with that reason. - A release that ends gone a second time within a week is held back for a day, whatever the cause. - release_blocks gains the reason 'gone' (migration 0098), shown as "Held back: its download client lost track of it". Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>	2026-10-21 11:31:57 -04:00
bvandeusenandClaude Opus 5.5	c54792c51e	feat: a held album below the quality you settle for, or holding a video rip, stays wanted for a better copy, and the import replaces the old tracks with their likes and plays carried over (M502 #5524) ... - acquisition_settings.upgrade_until (default High quality lossy, Lidarr's cutoff, note #5527; "" is off), an "Upgrade until" row under Searching. - The wanted worker judges held albums hourly: tier per format from size per second (the scanner records no bitrate), the album's worst. Below the cutoff it is wanted for quality; a video rip among its tracks always. - The schedule searches upgrades weekly, after open wants; a release no better than the copy held is refused ("not_better"). - The import matches each file to the track it would replace (recording, then disc/track) and replaces it when it is a rip or the file is a better tier: over the same path in one rename, or filed beside it and the old track folded in (library.ReplaceTrack: file first, then foldTrackInto). Nothing better: the release is set aside. - Collection › Upgrades (Lidarr's Cutoff Unmet); Suspect sources says when a clean copy was looked for instead of Lidarr's search. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>	2026-10-11 12:24:59 -04:00
bvandeusenandClaude Opus 5.5	8245f4406e	feat: download lifecycle — stalled and failed downloads are given up and searched again; imported ones seed, then go (M502 #5523) ... Ported from Fabled Librarian's System 104. A new lifecycle poller, every ten minutes: - a download the client fails is given up at once; - one nobody shares, or still fetching its file list, past the stall setting (6 h) is asked for again three times, then given up; - giving up removes the download with its files, holds the release back for a week (release_blocks.expires_at), ends the grab and searches the album again, with no limit per album; - a running download the client stops listing for half an hour ends and is searched again, not held back; an empty list is not taken as gone; - an imported download seeds to ratio 2.0 or 14 days, then is removed; - a download the client would not remove is asked again every pass. Every condition and act is one open row per (client, download, condition) in download_interventions. Activity shows what is wrong with a download and how often it was retried, why one ended, its seeding, and a banner for a client that does not answer. A running download can be given up by hand (set aside for good). The seed ratio, seed days and stall hours are on the search settings card. The download client lookup moves to acquire.DownloadClientFor, shared by the importer and the lifecycle. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>	2026-10-10 15:27:22 -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	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	a2e1890d4c	feat: indexers and download clients you add and configure (M502 #5518) ... Admin → Integrations gains "Indexers and download clients": two lists of connections the operator adds, Fabled Librarian's model. Nothing is seeded or copied from Lidarr. - Indexers: Prowlarr (its native /api/v1/search, which asks every indexer at once; Prowlarr has no aggregate Torznab feed) and any Torznab feed. - Download clients: qBittorrent (WebUI v2, with re-login on an expired session) and FabledExchange, one entry with a switch per job: downloads (/api/downloads), search (/api/search) and release details (/api/torrents/{infohash}). All three start on; its key is optional. - Each entry: enable, name, address, a write-only key or password, Test. A download client's Test lists its torrents and checks the downloads folder is visible and writable from Minstrel; an Exchange's Test reports each job switched on. - Download clients carry a path mapping (Minstrel's /downloads vs the client's own name for it); search sources carry searches per hour. Migration 0079 adds acquisition_services with its CHECKs. Ported from Fabled Librarian: internal/indexer (Torznab, 429 Retry-After, magnet redirects), internal/prowlarr, internal/exchange, internal/downloader, and internal/acquire's one builder per kind, which Test already uses so a passing Test vouches for the path a grab will take. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>	2026-10-09 20:34:51 -04:00