Release 0.1.1

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

chartarr/__init__.py

@@ -1,3 +1,3 @@
 """chartarr — feed your album charts to Lidarr."""
 
-__version__ = "0.1.0"
+__version__ = "0.1.1"