vavallee/bindery v1.39.1

on GitHub

Windows torrent imports, and single-file audiobooks that Rename files could damage

The Windows binary could not import from a torrent client running in Docker: every download failed with "no book files found" even though the file was there. That is fixed for qBittorrent, Transmission, Deluge and rTorrent, and the deployment guide now explains how to set Bindery's folders on Windows. Rename files no longer turns a single-file audiobook into a file with no extension; if it already happened to one of yours, the entry below says how to put it back. A single-file audiobook is now named from your audiobook file template when you have set one. No database changes.

Fixed

• Torrent imports work on the Windows binary when the download client runs in Docker (#2902): Bindery joined the client's save path and file names with Windows backslashes before applying the path remap, so a qBittorrent path such as /downloads/.Completed/Book/Vol 17.epub became \downloads\.Completed\..., a remap like /downloads:H:\Downloads never matched, and every import failed with "no book files found" although the file was there and Manual Import worked. Paths are now joined the way the client writes them and only turned into a Windows path after the remap, for qBittorrent (including the rdt-client content path fallback), Transmission, Deluge and rTorrent. On Windows the qBittorrent health check now suggests a remap in the client's own form and compares folders without regard to letter case, and the Windows binary no longer defaults BINDERY_DOWNLOAD_DIR to /downloads, a folder on whatever drive Bindery started from: unset, the health check only asks that the client's folder exists. File names from a download client that climb out of the torrent folder with ..\ are now refused on every platform. The deployment guide explains how to set environment variables on Windows and how to remap a Docker client's paths, and the Storage settings hint no longer mentions a config file that does not exist. Thanks fearvector on Discord for the report.
• Rename files no longer turns a single-file audiobook into a file with no extension (#2894): an audiobook tracked as the .m4b itself, which is what a library scan records for a flat Author/Title.m4b layout, was moved onto its templated folder path, so Stephen King/The Shining.m4b became a file named Stephen King/The Shining (1977). Rename then reported it as already correct, and an ebook import for the same book failed with not a directory. The file now moves inside the templated folder under its own name, its metadata.opf goes in that folder, and a file already in its folder stays put instead of being moved to Title (Year) (2). With a shared library root it joins the book's ebook folder, the same as an import. A file already flattened by the old behaviour is now shown as an error in Rename files instead of being moved again, and needs fixing by hand: move it into a folder and give it back its extension (for example The Shining (1977)/The Shining.m4b), use Forget this file on the book for the old path (not Delete, which removes it from disk), then run a library scan so Bindery picks up the folder. Thanks zikeji for the report and the fix.
• A single-file audiobook is now named from the audiobook file template (#2900): with naming.audiobook_file_template set, a folder of tracks was renamed but a lone .m4b kept its download name. It now gets the same name a track would, and so does a folder holding just one track. Put {Part} in a group with its own text, like {Title}{ - Pt. Part:3}.{ext}, and the group is left out when there is only one file, giving The Shining.m4b; written bare, as in {Title} - Part {Part:3}.{ext}, the single file is numbered as part 1. Settings now accepts {Part} inside such a group, which it used to reject. Rename files and the Fix Match preview propose the same name for a single-file audiobook already in the library. With no template set nothing changes. Thanks zikeji for the report.