Lidarr: album adds that Lidarr accepts, artist monitoring that sticks #138

Merged

bvandeusen merged 2 commits from dev into main 2026-10-07 11:08:18 -04:00

Conversation 0 Commits 2 Files Changed 4

+235 -55

bvandeusen commented 2026-10-07 11:08:14 -04:00

Owner

Copy Link

Copy Source

Two fixes to the payloads Minstrel sends Lidarr. Both were the same kind of bug: a shape that only a fake server ever accepted.

• #5234, album add (670b30c9). Lidarr validates artist as a nested resource, so every album or track-kind add was refused with "'Artist' must not be empty". Approved album requests sat in the reconciler failing every 5 minutes (about 40 on the deploy). The add now mirrors Lidarr's own UI: look the album up by MBID, then POST that resource back. A new artist monitors only the requested album, with no catalogue search and no future releases. An existing artist is left untouched.
• #5239, artist add (bf6364b7). The all/future monitor choice was sent at the top level, where ArtistResource has no field, so Lidarr dropped it and never applied it. It now goes in addOptions.monitor, and monitorNewItems is set explicitly.

CI: run 8520 (670b30c9) and run 8524 (bf6364b7) passed every verifying lane.

🤖 Generated with Claude Code

Two fixes to the payloads Minstrel sends Lidarr. Both were the same kind of bug: a shape that only a fake server ever accepted. - **#5234, album add (`670b30c9`).** Lidarr validates `artist` as a nested resource, so every album or track-kind add was refused with "'Artist' must not be empty". Approved album requests sat in the reconciler failing every 5 minutes (about 40 on the deploy). The add now mirrors Lidarr's own UI: look the album up by MBID, then POST that resource back. A new artist monitors only the requested album, with no catalogue search and no future releases. An existing artist is left untouched. - **#5239, artist add (`bf6364b7`).** The `all`/`future` monitor choice was sent at the top level, where ArtistResource has no field, so Lidarr dropped it and never applied it. It now goes in `addOptions.monitor`, and `monitorNewItems` is set explicitly. CI: run 8520 (670b30c9) and run 8524 (bf6364b7) passed every verifying lane. 🤖 Generated with [Claude Code](https://claude.com/claude-code)

bvandeusen added 2 commits 2026-10-07 11:08:14 -04:00

fix(lidarr): add an album as the looked-up resource with its artist nested (#5234) ... 670b30c954

Lidarr's POST /api/v1/album validates `artist` as a nested resource
(AlbumController: RuleFor(s => s.Artist).NotNull()), so the flat payload
we sent was refused with "'Artist' must not be empty" every time. The
album add has never worked against a real Lidarr; approved album and
track requests sat in the reconciler retrying every 5 minutes.

AddAlbum now does what Lidarr's own add-album UI does (getNewAlbum /
getNewArtist): look the album up by MBID (album/lookup?term=lidarr:<mbid>),
then POST that resource back with monitored + searchForNewAlbum. When
Lidarr doesn't have the artist yet, the nested artist gets the request's
quality/metadata profile and root folder, monitors this album only
(monitor "none" + albumsToMonitor, which AlbumMonitoredService prefers)
and no future releases. An artist Lidarr already has is left as it is.
An MBID Lidarr's metadata doesn't know is ErrNotFound with no POST.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

fix(lidarr): send the artist add's monitor choice in addOptions (#5239) ... bf6364b709

ArtistResource has no top-level `monitor`. Lidarr reads the choice from
AddOptions (AddArtistOptions, a MonitoringOptions), so the "all"/"future"
we sent there was dropped on deserialisation. AddOptions.Monitor stayed
Unknown, and AlbumMonitoredService.SetAlbumMonitoredStatus returns early
on Unknown. The request's monitoring was never applied.

Send monitor and monitored inside addOptions with searchForMissingAlbums,
the shape Lidarr's getNewArtist.js posts, and set monitorNewItems "all"
explicitly: both choices mean new releases are watched.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

bvandeusen merged commit 22ea27efff into main 2026-10-07 11:08:18 -04:00

Sign in to join this conversation.

Reviewers

No Reviewers

Labels

Clear labels

deps

Dependency update (Renovate)

deps:major

Major dependency bump — held for manual review

No labels

Milestone

No items

No Milestone

Projects

Clear projects

No projects

Assignees

Clear assignees

renovate-bot bvandeusen

No Assignees

1 Participants

Notifications

Subscribe

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: bvandeusen/minstrel#138