5 Commits

Include renames

Author	SHA1	Message	Date
bvandeusenandClaude Opus 5.5	670b30c954	fix(lidarr): add an album as the looked-up resource with its artist nested (#5234) ... 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
bvandeusenandClaude Opus 4.7	7d33166f23	fix(lidarr): include artistName + metadataProfileId on add-artist/add-album ... The 'lidarr_rejected' the operator was hitting on Approve was Lidarr 4xx-ing the POST with two field-validation errors: 'Metadata Profile Id' must be greater than '0'. 'Artist Name' must not be empty. Our payload was missing both. Lidarr's metadata profile is a separate concept from quality profile (it controls which release types are tracked: albums, singles, EPs, etc.) and is required by /api/v1/artist and /api/v1/album. The 'already exists' line in the toast copy was an incorrect guess at the cause; the real issue was an invalid payload. Changes: - internal/lidarr/types.go: AddArtistParams + AddAlbumParams gain ArtistName and MetadataProfileID. New MetadataProfile struct mirroring QualityProfile. - internal/lidarr/client.go: AddArtist + AddAlbum payloads include both new fields. New ListMetadataProfiles fetches GET /api/v1/metadataprofile. - internal/lidarrrequests/service.go: Approve fetches the metadata profile list and uses the first as a default (Lidarr installs ship 'Standard' at id=1 OOB, so this works for vanilla setups). Picker on /admin/integrations is a follow-up. ArtistName flows from the request row. - web/src/routes/admin/requests/+page.svelte: drop the speculative 'usually means already in library' copy on lidarr_rejected; point operators at server logs for the field-level reason instead. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>	2026-05-01 23:57:39 -04:00
bvandeusen	f2cdd23fd5	feat(lidarr): LookupArtistByMBID, LookupAlbumByMBID, DeleteAlbum	2026-04-30 16:57:14 -04:00
bvandeusenandClaude Sonnet 4.6	ebff8f69a0	fix(lidarr): address review findings on HTTP client ... - Add ArtistMBID/AlbumMBID to LookupResult so handlers can build the full lidarr_requests row from album/track lookups (parent MBID is needed for the AddAlbum API call and for the schema's NOT NULL lidarr_artist_mbid) - Trim trailing slash on BaseURL before joining paths to avoid double-slash URLs when operators enter "http://lidarr.lan/" - Check json.Marshal errors in AddArtist/AddAlbum - Extract lidarrImage as a named unexported type instead of repeating the anonymous struct three times - Add NewClient(baseURL, apiKey) constructor with 30s default timeout - Add ErrLookupFailed test coverage for the 4xx-non-auth branch on both get and post helpers - Rename TestListRootFolders_BadJSON -> _NullBody (it tests null, not malformed); add a real malformed-JSON test - Defensive separator guard on LookupAlbum.Secondary so an empty ArtistName doesn't produce a leading " · " Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>	2026-04-29 16:26:23 -04:00
bvandeusenandClaude Sonnet 4.6	a43fa09a04	feat(lidarr): typed HTTP client for v1 API (lookup, add, profiles, ping) ... Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>	2026-04-29 15:25:10 -04:00