Indexers that rate limit are left alone properly, plus import fixes
An install with a large wanted list was sending one indexer over 2,000 refused searches in a single sweep, because a rate limit from Cloudflare in front of the indexer was not recognised, and that kept Sonarr and Radarr locked out of the same tracker. Bindery now stands back from an indexer that says it is rate limited, for longer each time it keeps refusing, and the Indexers tab shows when searches resume. The rest are fixes: Audiobookshelf imports stop re-monitoring books you unmonitored, Calibre imports see edits Calibre has not checkpointed yet, and Add Book and the bulk imports stop linking to a fallback provider, or waiting on every row, while your primary metadata provider is down. The Series page also gets a title search.
Added
- Search the Series page by title (#2634): a search box at the top of the Series page filters your series as you type, ignoring case and accents, the same way the Authors and Books pages do. Thanks magrhino, who built it.
Changed
- A rate limited indexer is left alone for longer each time it refuses (#2640): the hold after a request limit was always one hour unless the indexer named a time, so a tracker whose window is longer than that got one refused request every hour until it cleared, and trackers that count refused requests never cleared. Repeated limits now step up through three hours, six, twelve and a day, the same steps Sonarr and Radarr use, and every search the indexer answers steps back down. The indexer's own Retry-After or "retry in" time still wins when it sends one.
- The Indexers tab shows a held indexer and when its searches resume (#2640): until now the hold was only visible in a search's details panel, so an indexer that had been benched for a day looked idle in Settings.
Fixed
- An indexer that rate limits at the HTTP layer now gets a cooldown (#2635): Bindery already stood back for an hour, or for as long as the indexer asked, when a Newznab indexer answered a search with its own "request limit reached" error. A limit applied by the host in front of the indexer, such as Cloudflare's HTTP 429 "error code: 1015", was not recognised, so every search in a wanted sweep sent that indexer another request it had already refused: over 2,000 in one run on a 3,300 book library, and enough to keep Sonarr and Radarr locked out of the same tracker for hours. An HTTP 429, or a 503 that names a Retry-After, now puts the indexer in the same cooldown, honouring Retry-After when the server sends one, and a search that hits it stops trying its remaining query variations against that indexer. A 503 with no Retry-After is still treated as a passing outage.
- An Audiobookshelf import no longer re-monitors books you unmonitored (#2632): every book an import matched to an existing Bindery record was set back to monitored, whatever you had chosen, so one run could take a curated library from a few hundred monitored books to nearly every book it holds, and Bindery then went searching indexers for all of them. The update path now leaves Monitored as you set it; only a book the import creates is monitored. Same decision as the list syncer fix in v1.33.0. Thanks Broomfundel for the report.
- Calibre library imports now see edits Calibre has not checkpointed yet (#2631): Bindery opened
metadata.dbwith SQLite'simmutable=1flag, which ignores the write-ahead log entirely. With Calibre-Web-Automated, the Calibre content server or any long running Calibre holding the library open, that meant Bindery read a snapshot as of the last checkpoint, sometimes a day old: an author merged or deleted in Calibre kept coming back on every import. The reader now opens the database plain read-only so the WAL is honoured. If that open fails, for example because the library directory is mounted read-only with nometadata.db-shmfile or the library sits on an NFS or SMB share, Bindery falls back to the old behaviour and logs a warning saying that Calibre edits will stay invisible until Calibre checkpoints. Thanks Broomfundel for the report. - A qBittorrent download with no content path on this host no longer sits in progress forever (#2616): when qBittorrent reported a download complete but sent no content path and nothing was at its save path, the Queue showed it as grabbed indefinitely while the log repeated "will retry next cycle". It now fails the import with a message saying the files are missing or the paths don't map into Bindery, retries if the files turn up, and is blocked once they never do, like any other import whose files are gone. Thanks tunglambk, who built the fix.
- Add Book no longer takes a fallback provider's record while the primary is down (#2612): searching an ISBN in the Add Book dialog, and adding a book whose result has no author id (such as a DNB result), both look the ISBN up across the metadata providers. When the primary provider timed out, the lookup quietly moved on to the next provider, and adding what it found gave the book and its author that provider's ids for good, which later produced a duplicate author once the primary was back. The ISBN search and the add now say the primary metadata provider did not answer and to try again once it responds, and the fallback's answer is no longer cached, so the next search asks the primary again. A primary that answers and simply has no record for the ISBN still lets the other provider's record through, as before. This is the same guard the CSV, Readarr and Goodreads imports gained in #2332.
- Imports no longer wait out a down primary metadata provider on every row (#2613): with the primary not answering, the CSV author import, the Readarr import and the Goodreads preview waited out its timeout on every row, only to fail the row anyway because a fallback match cannot be linked while the primary is down. That was 8 seconds per author, so a 200 author list ran for about 27 minutes and the browser gave up long before, and up to a minute per ISBN lookup on Goodreads, which turned a large export into hours. After three lookups in a row get no answer from the primary, the import stops asking it and lists every remaining row as failed with the same "did not answer, run the import again once it responds" reason. A lookup the primary answers resets the count.