From 56dfc6d0b90a2c7c6e54d5dac394293ba7da9235 Mon Sep 17 00:00:00 2001 From: Frank Date: Mon, 2 Nov 2026 02:57:25 -0800 Subject: [PATCH] docs(audiobookshelf): the scanner refusal names the file, not the bind The first full scan logged "Invalid data found when processing input" per file and carried on. That line is about the file: the scanner skips it, so the book never appears in the library at all. Census of the 43 refused files: 38 were 0 bytes, 3 held WAV bytes behind a .mp3 name, 2 were unreadable. The check to run first is a byte count, not a server investigation. Full suite: 818 tests, exit 0. --- serverAppConfigs-docs/Dankserver/Audiobookshelf.md | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/serverAppConfigs-docs/Dankserver/Audiobookshelf.md b/serverAppConfigs-docs/Dankserver/Audiobookshelf.md index e079d20..f490b24 100644 --- a/serverAppConfigs-docs/Dankserver/Audiobookshelf.md +++ b/serverAppConfigs-docs/Dankserver/Audiobookshelf.md @@ -124,6 +124,12 @@ the file, not the bind: the same line count grows while the total climbs. cross a rootless podman bind — measured for [[Jellyfin]], whose page owns that law — so the in-container watcher sees nothing a host process files onto the array, and the deployer's re-run of the bootstrapper is the cheap scan trigger. +- **`Invalid data found when processing input` names the file, not the bind.** The + scanner logs it per file and skips the file — the book never appears — so a + missing title beside those lines is library debris, not a server fault. Census of + the refusals on the first full scan: 38 of 43 files were 0 bytes, 3 were WAV + bytes wearing a `.mp3` name, 2 were unreadable. `stat -c %s` before any + investigation of the server. ## Verification