From 4481c1695679ead1ceeab2bc3c175ee6e6b05da8 Mon Sep 17 00:00:00 2001 From: alperien Date: Tue, 28 Jul 2026 15:20:05 +0500 Subject: [PATCH] release: 0.1.1 Four fixes since 0.1.0, led by the review screen pinning a CPU core. Co-Authored-By: Claude --- CHANGELOG.md | 109 ++++++++++++++++++++++--------------------- chartarr/__init__.py | 2 +- 2 files changed, 58 insertions(+), 53 deletions(-) diff --git a/CHANGELOG.md b/CHANGELOG.md index 1f51c74..8d14938 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -9,63 +9,67 @@ alone. ## [Unreleased] -### Fixed +## [0.1.1] - 2026-07-28 + +A fix release. The first one is the reason to upgrade. -- **One failed search request no longer strands the albums behind it.** - Searches go out in batches of a hundred, and a batch that failed raised - immediately, so on a 250-album chart a single timed-out request left the - last fifty albums unsearched with nothing said about it. Every batch is - now attempted, and the summary reports how many albums missed out and - why. -- **`--search` did not start downloads for the first album of each new - artist.** Adding an album was assumed to search it, via Lidarr's - `addOptions.searchForNewAlbum`. That flag is read by - `SearchForRecentlyAdded`, which Lidarr's `ArtistScannedHandler` only - reaches for an artist that has no pending add options — never the - artist the add just created — and the handler clears those options on - its way out, so the flag is stored and dropped - ([Lidarr#5012](https://github.com/Lidarr/Lidarr/issues/5012)). The - second and later albums by an artist were unaffected: Lidarr - pre-creates the discography, so those come back "already added" and - take the flip-to-monitored path, which chartarr 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, instead of looking - like a finished job that downloaded nothing. - -- **A skip in the review screen is now honoured on a row that also - matched.** The push took the automatic match whenever there was one and - only consulted your decision otherwise, so a row that was skipped and - then matched on a later `--rematch` went to Lidarr anyway, and a re-pick - lost to the candidate the matcher had led with. A decision now outranks - the match result. A matched row carrying no release group id — possible - in a state file written by an older version — is left out instead of - failing at Lidarr's lookup. -- **A Lidarr URL with credentials in it no longer appears in error - messages.** `http://user:pw@host` is how you get through a reverse proxy - that asks for basic auth, and the whole URL was quoted back in every - connection error, timeout and proxy error page. The password is stripped - from what's printed; the request still sends it. +### Fixed - **The review screen pinned a CPU core while it waited for you.** The - progress screens poll for a keypress so they can notice `q` mid-run, and - that non-blocking mode stayed on the window afterwards — `curses.wrapper` - does not reset it between screens. The review list, which expects to wait - for input, instead read "no key pressed" and redrew immediately, about - 17,000 times a second for as long as the screen was open. It also - flickered. Every screen now starts in blocking mode. -- **`--search` asked Lidarr to search newly added albums twice.** An added - album already carries `searchForNewAlbum`, and it was then named in the - follow-up `AlbumSearch` command as well. Only albums that were flipped - from unmonitored to monitored need that second request, since the flag - never fires for them. + progress screens poll for a keypress so they can notice `q` mid-run, + and that non-blocking mode stayed on the window afterwards — + `curses.wrapper` does not reset it between screens. The review list, + which expects to wait for input, read "no key pressed" instead and + redrew immediately: about 17,000 times a second, for as long as the + screen was open. It flickered, and on a laptop you could hear it. Every + screen now starts in blocking mode. Waiting on the review list costs + one redraw and no measurable CPU. +- **A skip or a re-pick was ignored on a row that also matched.** The + push took the automatic match whenever there was one and consulted your + decision only otherwise, so a row you skipped that later matched on a + `--rematch` went to Lidarr anyway, and a re-pick lost to the candidate + the matcher had led with. A decision now outranks the match result. A + matched row carrying no release group id — possible in a state file + from an older version — is left out instead of failing at Lidarr's + lookup. +- **One failed search request stranded the albums behind it.** Searches + go out in batches of a hundred and a failing batch stopped the rest, so + on a 250-album chart a single timed-out request left the last fifty + unsearched, reported as one line that did not say how many albums it + had cost. Every batch is attempted now, and the summary says how many + albums missed out and why. +- **A Lidarr URL with credentials in it appeared in error messages.** + `http://user:pw@host` is how you get through a reverse proxy that asks + for basic auth, and the whole URL was quoted back in connection errors, + timeouts, non-JSON replies and proxy error pages — the kind of text + that ends up pasted into a bug report. The password is stripped from + what's printed; the request still sends it. ### Added -- **u undoes a decision in the review screen.** A mistyped `s` used to be - permanent for that run — the state file has always understood a cleared - decision, but nothing could write one. -- Tests for the review screen's keys, which had none. +- **`u` undoes a decision in the review screen.** A mistyped `s` used to + be permanent for that run: the state file has always understood a + cleared decision, but nothing could write one. +- **A push without `--search` now says how many albums are monitored but + idle.** Monitoring is not downloading — Lidarr picks monitored albums + up on its own schedule — and a run ending "added 40" while nothing + downloads reads like a finished job. + +### Changed + +- chartarr no longer sends `addOptions.searchForNewAlbum` when it adds an + album. Lidarr stores the flag and drops it unread for an artist created + by the same request ([Lidarr#5012](https://github.com/Lidarr/Lidarr/issues/5012)), + so it never did anything; the explicit `AlbumSearch` command was always + the thing starting downloads. No change in behaviour, one less + misleading field on the wire. + +### Internal + +- The review screen's keys had no tests, which is how the redraw bug + shipped. They have 19 now, driven through a fake curses window, plus a + pty test that the non-blocking flag cannot survive a screen. 97 tests + at 0.1.0, 142 here. ## [0.1.0] - 2026-07-27 @@ -96,5 +100,6 @@ changed behaviour you may have been affected by: nothing ever looked at those rows again. The run now stops instead, and `--rematch` re-queries rows nothing was found for. -[Unreleased]: https://github.com/alperien/chartarr/compare/v0.1.0...HEAD +[Unreleased]: https://github.com/alperien/chartarr/compare/v0.1.1...HEAD +[0.1.1]: https://github.com/alperien/chartarr/compare/v0.1.0...v0.1.1 [0.1.0]: https://github.com/alperien/chartarr/releases/tag/v0.1.0 diff --git a/chartarr/__init__.py b/chartarr/__init__.py index 94fd9e8..4cb0f1f 100644 --- a/chartarr/__init__.py +++ b/chartarr/__init__.py @@ -1,3 +1,3 @@ """chartarr — feed your album charts to Lidarr.""" -__version__ = "0.1.0" +__version__ = "0.1.1"