Six fixes for things Bindery was getting wrong without ever saying so.
Every entry here is a silence, not an error message. A grab that worked reported as
failed. Books you excluded quietly coming back. An ebook that no quality profile
would ever allow, on a path with no human watching. A track disappearing from a
multi-file audiobook. The one thread running through most of them is a check
answering a question it was never asked, or an absence being read as an answer.
Fixed
- Grabs against rdt-client and other qBittorrent API emulators are no longer all marked failed (#2304). Those clients answer
POST /torrents/addwith HTTP 200 and no body, where qBittorrent itself writesOk.. Bindery read the empty body as a rejection and failed every grab withadd torrent failed:and no message, while the torrent had in fact been accepted, downloaded to completion, and then sat there unimported. An empty body on a 200 is now an accept; a non-empty rejection body such asFails.still fails the grab, and a response Bindery could not finish reading now fails loudly instead of being mistaken for an empty one. Thanks to Gamegenie13 for the report. - A quality profile no longer blocks the format it was never asked about (#2307). An author gets one quality profile, so if you built yours around audiobook containers (m4b, mp3, flac) then every ebook release for that author was rejected as "format not in quality profile", and the reverse for an ebook profile and audiobook releases. On the Search page that only showed as a misleading warning, since Grab stayed enabled. On the automatic path it was silent and much worse: the book could never be auto-grabbed at all, and the same check runs at import, so a file in the other format would not import either. A release is now judged only against the profile entries of its own media type, and passes when the profile lists none of them. Within a media type the profile does describe, nothing changes: a format you unticked stays rejected, and a profile that deliberately lists both behaves exactly as before. A file whose content belongs to the other media type is still kept out of the wrong slot, which the profile had been doing by accident. Thanks to clebcleb for the report and to KadenTheHero for working out that the profile has no media type to reason with.
- Series fill no longer re-acquires the books you excluded (#2302). Every series query returned excluded books, so filling a series marked them wanted and searched for them again, which is the opposite of what excluding a book means, and applying genres to a series wrote them onto excluded books too. Series listings now skip excluded books the way the author listings already did. The one place that still counts them is an import rollback deciding whether a series is now empty, because an excluded book still occupies the series. Thanks to hoxtonia for the report and to thejdubb02 for the fix.
- An audiobook no longer imports into a "Title (2)" folder when the ebook is already there (#1959). Under the shared-folder layout, where
BINDERY_AUDIOBOOK_DIRis unset so both formats resolve to the same folder, importing a book's audiobook after its ebook created a sibling duplicate instead of joining it. It now merges into the book's existing folder. A same-named file already there, cover art carried by both formats being the usual case, is skipped rather than overwritten, and the skipped names are recorded on the import's History entry and thebookImportednotification. Libraries using the per-file audiobook naming template or multi-disc flattening still split, because those paths own the folder they create and merging them safely needs their rollback reworked first. Thanks to Daize for the request and to schmitzkr for the fix. - A "Books 1-4" pack is no longer auto-grabbed for a single book (#2276). An automatic search for one book could select an explicit multi-book release, and since a download is linked to exactly one book, the importer then tried to place every file in the pack into that one book's folder. Automatic selection now skips releases that name themselves as a pack: a numbered range like
Books 1-4, a box set, an omnibus, a "complete series". They still appear in interactive search so you can see and grab one deliberately, and if you do, the import is blocked with an explanation instead of running. Queue, Manual import is the way to take a pack. The wording is judged narrowly:Part 1-2is how a single long audiobook is split andTrilogyis how single books name their series, so neither counts, and if the book you track is itself a bundle then matching packs are still allowed for it. Thanks to magrhino for the report. - A multi-file audiobook could lose a track, silently, when two of its files shared a filename (#2275). Downloads whose book files share no folder below the download root are placed one file at a time and flattened into the book's folder by filename, so two tracks from different source folders with the same name both claimed the same destination. In
hardlinkmode the second failed with "file exists" and left a half-imported folder the book never recorded; incopyandmovemode it silently replaced the first, and inmovethat track's contents were gone for good. Bindery now projects every destination name before it creates anything and blocks the import, naming both source files and the path they share, with nothing written and both files left in the download folder. The drop-folder handoff had the same flatten and is covered by the same check. A placement error that cannot be predicted, a full disk or a revoked permission, now also undoes what it placed instead of leaving a partial folder that made the next retry build a second one. Hardlink failures also stopped blaming your filesystem layout for unrelated errors: every failedos.Linkthat was not a cross-device error reported "download dir and library must be on the same filesystem", so a destination collision on a single dataset sent you to check mounts that were fine. A missing source, a permissions problem and an existing destination now each say what they are. Thanks to magrhino for the report.