bvandeusen/minstrel
1
0
Fork 0
Code Issues 2 Pull Requests Actions 1 Packages Projects Releases 52 Wiki Activity

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
2 Commits
Author SHA1 Message Date
bvandeusenandClaude Opus 5.5 bf6364b709 fix(lidarr): send the artist add's monitor choice in addOptions (#5239)
release / govulncheck (push) Successful in 29s
Details
release / web (push) Successful in 1m58s
Details
release / go (push) Successful in 2m14s
Details
release / integration (push) Successful in 5m17s
Details
release / android (push) Successful in 6m21s
Details
release / Build signed APK (releases and dev) (push) Successful in 6m38s
Details
release / Attach APK to the Release (tag releases only) (push) Skipped
Details
release / Build + push container image (push) Successful in 2m1s
Details
release / Verify release artifacts (tag releases only) (push) Skipped
Details 
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>
 2026-10-07 10:58:55 -04:00
bvandeusenandClaude Opus 5.5 670b30c954 fix(lidarr): add an album as the looked-up resource with its artist nested (#5234)
release / web (push) Successful in 1m42s
Details
release / go (push) Successful in 2m7s
Details
release / govulncheck (push) Successful in 37s
Details
release / integration (push) Successful in 5m31s
Details
release / Attach APK to the Release (tag releases only) (push) Canceled after 0s
Details
release / Build + push container image (push) Canceled after 0s
Details
release / Verify release artifacts (tag releases only) (push) Canceled after 0s
Details
release / android (push) Canceled after 5m14s
Details
release / Build signed APK (releases and dev) (push) Canceled after 4m42s
Details 
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>
 2026-10-07 10:55:41 -04:00