fix: survive an album with two monitored releases #3

2026-08-24T14:25:23+01:00

lyrathorpe commented

2026-08-24 14:25:23 +01:00

Problem

ERROR GET https://lidarr.../api/v1/album: HTTP 500: Sequence contains more than one element

Moving to the unfiltered album endpoint in #2 avoided Lidarr's unguarded
per-artist path, but not the exception underneath it. Every album endpoint maps
through AlbumResource.ToResource, which selects the release with:

var selectedRelease = model.AlbumReleases?.Value.SingleOrDefault(x => x.Monitored);

An album with two monitored releases makes that throw, and the bulk call
loses the entire library to one bad row. The unfiltered endpoint guards the
artist-metadata lookup; it does not guard this.

Change

Keep the unfiltered call as the first attempt -- it is a single request, and it
is still the only path that skips albums whose artist metadata is missing. When
it fails, fall back to one request per artist. That cannot dodge the exception
either, but it confines the loss to whichever artist owns the offending album
and names them in the log, which is the only practical way to find it in a
large library.

Album failures are counted separately from artist failures, because they do not
mean the same thing:

Failure	Effect
Artist's tracks missing	Their played music reads as unplayed. Blocks matching and any cull.
Artist's albums missing	Tracks still index and still match. Blocks only the cull.

Lumping them into one warning would overstate the damage and invite the wrong
fix.

Fixing the data

The log now names the artist. In Lidarr, open them and check the Releases tab
of each album: exactly one release per album may be monitored. Until that is
done, matching works and the cull stays blocked, which is the correct order of
events.

Testing

46 tests, green locally and in docker build --target test. New ones cover the
fallback firing, the offending artist being the only one to lose its albums,
and that artist keeping its tracks -- tracks come from a different endpoint
with a different mapper, so matching survives.

## Problem ERROR GET https://lidarr.../api/v1/album: HTTP 500: Sequence contains more than one element Moving to the unfiltered album endpoint in #2 avoided Lidarr's unguarded per-artist path, but not the exception underneath it. Every album endpoint maps through `AlbumResource.ToResource`, which selects the release with: var selectedRelease = model.AlbumReleases?.Value.SingleOrDefault(x => x.Monitored); An album with **two monitored releases** makes that throw, and the bulk call loses the entire library to one bad row. The unfiltered endpoint guards the artist-metadata lookup; it does not guard this. ## Change Keep the unfiltered call as the first attempt -- it is a single request, and it is still the only path that skips albums whose artist metadata is missing. When it fails, fall back to one request per artist. That cannot dodge the exception either, but it confines the loss to whichever artist owns the offending album and names them in the log, which is the only practical way to find it in a large library. Album failures are counted separately from artist failures, because they do not mean the same thing: | Failure | Effect | | ------------------------ | ------------------------------------------------ | | Artist's tracks missing | Their played music reads as unplayed. Blocks matching and any cull. | | Artist's albums missing | Tracks still index and still match. Blocks only the cull. | Lumping them into one warning would overstate the damage and invite the wrong fix. ## Fixing the data The log now names the artist. In Lidarr, open them and check the Releases tab of each album: exactly one release per album may be monitored. Until that is done, matching works and the cull stays blocked, which is the correct order of events. ## Testing 46 tests, green locally and in `docker build --target test`. New ones cover the fallback firing, the offending artist being the only one to lose its albums, and that artist keeping its tracks -- tracks come from a different endpoint with a different mapper, so matching survives.

lyrathorpe added 1 commit 2026-08-24 14:25:23 +01:00

fix: survive an album with two monitored releases

Build and publish container / build (pull_request) Successful in 8m11s

Details

997627f4fe

Fetching every album in one unfiltered request avoided Lidarr's unguarded
per-artist path, but not the exception underneath it. Every album endpoint maps
through AlbumResource.ToResource, which selects the release with
SingleOrDefault(x => x.Monitored). An album with two monitored releases makes
that throw -- "Sequence contains more than one element" -- and the bulk call
loses the entire library to one bad row.

Keep the unfiltered call as the first attempt, since it is a single request and
is still the only path that skips albums whose artist metadata is missing. When
it fails, fall back to one request per artist. That cannot dodge the exception
either, but it confines the loss to whichever artist owns the offending album
and names them, which is the only practical way to find it in a large library.

Album failures are counted separately from artist failures because they do not
mean the same thing. Tracks come from a different endpoint with a different
mapper, so an artist whose albums cannot be fetched still gets indexed and still
matches; it is the cull that cannot run. The report distinguishes the two rather
than lumping them into one warning that overstates the damage.

lyrathorpe merged commit aa2bd59320 into main

2026-08-24 14:25:50 +01:00

lyrathorpe deleted branch fix/lidarr-monitored-release-clash

2026-08-24 14:25:52 +01:00

lyrathorpe referenced this pull request

2026-08-24 14:40:45 +01:00

fix: hold one connection to Lidarr open, and retry what deserves retrying #4

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: lyrathorpe/music-curator#3