--search now starts downloads for every album it pushes by alperien · Pull Request #6 · alperien/chartarr

alperien · 2026-07-27T21:29:57Z

The first album of each new artist was never searched. On a chart with one album per artist — the normal case — that's every album.

This corrects a mistake I made in #4. There I removed added albums from the explicit search, reasoning that addOptions.searchForNewAlbum already covered them. It doesn't.

Why the flag does nothing

Verified in Lidarr's source, not inferred — ArtistScannedHandler.HandleScanEvents:

var addOptions = artist.AddOptions;
if (addOptions == null)
{
    _albumAddedService.SearchForRecentlyAdded(artist.Id);   // the ONLY consumer
    return;
}
// ... post-add actions ...
artist.AddOptions = null;      // and now it's gone

SearchForRecentlyAdded is the only thing that reads searchForNewAlbum, and it's unreachable for an artist that has AddOptions — which is precisely the artist the add just created. The handler then clears them. The flag is stored and dropped. That's Lidarr#5012, still open.

Why it hid: second-and-later albums by an artist were fine. Lidarr pre-creates the discography, so those POSTs come back 400 "already been added" (AlbumExistsValidator), take the flip-to-monitored path, and were searched explicitly. Only the album that opened each artist fell through.

The fix

Every album this run adds or turns on is named in one AlbumSearch command — which searches unconditionally, with no monitored filter, unlike MissingAlbumSearchCommand. The dead flag is gone from the payload; leaving it false also keeps AddAlbumService from tangling it with searchForMissingAlbums.

Also: without --search, the summary now says how many albums are monitored but idle. Monitoring isn't downloading, and a push ending added 40 while nothing downloads reads like a finished job.

Verification

Against a stand-in Lidarr that pre-creates discographies and 400s duplicates — three albums by one artist, one added and two flipped:

this branch:   ids pushed [101, 102, 103]  →  searched [101, 102, 103]  ✓
previous main: ids pushed [101, 102, 103]  →  searched [102, 103]       ✗

138 tests passing on Python 3.10 and 3.12; ruff clean
uv build + twine check --strict pass
Three tests that asserted the old behaviour were rewritten, not deleted — each now documents why

The confirm-screen and --no-search UX from fix/robustness-audit is deliberately left out: that's a preference, this is correctness. Easy to add later if you want it.

This is the last blocker for v0.1.1 — the regression is live on main right now.

The first album of each new artist was never searched: lidarr stores addOptions.searchForNewAlbum and drops it unread for an artist created by the same request (Lidarr#5012). Every album this run adds or turns on is now named in one AlbumSearch command. Co-Authored-By: Claude <noreply@anthropic.com>

coderabbitai · 2026-07-27T21:30:08Z

Warning

Review limit reached

@alperien, you've reached your PR review limit, so we couldn't start this review.

Next review available in: 47 minutes

Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available.
You're only billed for reviews past your plan's rate limits ($0.25/file).

How can I continue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews.

How do review limits work?

CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability.

For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window.

Please refer docs for additional details.

Review details

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro Plus

Run ID: f0fa935e-b552-411d-a371-24af925e75fc

📥 Commits

Reviewing files that changed from the base of the PR and between b0da5ff and 739caf4.

📒 Files selected for processing (6)

CHANGELOG.md
README.md
chartarr/cli.py
chartarr/lidarr.py
tests/test_cli.py
tests/test_lidarr.py

✨ Finishing Touches

🧪 Generate unit tests (beta)

Create PR with unit tests
Commit unit tests in branch fix/start-downloads

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

_{Comment @coderabbitai help to get the list of available commands.}

Version bump and changelog. No code changes; everything here landed in #4, #5, #6 and #7. Four fixes since 0.1.0, led by the review screen redrawing about 17,000 times a second while it waited for a keypress. Also: a skip or re-pick ignored on a row that also matched, one failed search request stranding the albums behind it, and basic-auth credentials appearing in error messages. Adds the u undo key and an idle-albums note when --search is off. The --search round trip between #4 and #6 is deliberately absent from the changelog: 0.1.0 already searched correctly, and nothing shipped in between, so there is no user-visible bug to report. The dead searchForNewAlbum flag's removal is recorded under Changed. Co-Authored-By: Claude <noreply@anthropic.com>

The first album of each new artist was never searched, so on a chart of one album per artist, nothing downloaded. Adding an album was assumed to search it via lidarr's addOptions.searchForNewAlbum. That flag is read by SearchForRecentlyAdded, which ArtistScannedHandler reaches only for an artist with no pending AddOptions -- never the artist the add just created -- and the handler clears them on the way out, so the flag is stored and dropped (Lidarr#5012, open). Verified in lidarr's source. Second and later albums by an artist were fine, which is why this hid: lidarr pre-creates the discography, so those come back 400 "already been added", take the flip-to-monitored path, and were searched explicitly. Every album this run adds or turns on is now named in one AlbumSearch command, which searches unconditionally. Without --search, the summary says how many albums are monitored but idle. Verified against a stand-in lidarr that pre-creates discographies and 400s duplicates: three albums by one artist, all three searched exactly once; the previous commit searches two of three. 138 passing.

Version bump and changelog. No code changes; everything here landed in #4, #5, #6 and #7. Four fixes since 0.1.0, led by the review screen redrawing about 17,000 times a second while it waited for a keypress. Also: a skip or re-pick ignored on a row that also matched, one failed search request stranding the albums behind it, and basic-auth credentials appearing in error messages. Adds the u undo key and an idle-albums note when --search is off. The --search round trip between #4 and #6 is deliberately absent from the changelog: 0.1.0 already searched correctly, and nothing shipped in between, so there is no user-visible bug to report. The dead searchForNewAlbum flag's removal is recorded under Changed.