What went wrong?
When investigating Bug#333 I came across another issue, but with the Metadata system. When Bookorbit fetches metadata from Hardcover (e.g. when searching for a book to add to the library), it can select an audiobook edition as the primary result, despite the file being an epub. This results in an odd metadata entry saved to the Bookorbit database: it displays a physical page count (e.g., 1243 pages) but silently stores the audiobook's ISBN. Consequently, any future Hardcover integration syncs perfectly match against the wrong edition, an audiobook in this instance.
Note: I am not a coder, but I've dabbled with using LLM for solving simple personal software needs and some of the specific technical details identified below are from it.
Steps to reproduce
- Go to the Bookorbit metadata search UI and search for a book with multiple editions (e.g., Oathbringer by Brandon Sanderson).
- Look at the Hardcover provider tab results.
- Observe that the first candidate often has the correct page count (e.g., 1243p) but is mapped to an audiobook or GraphicAudio edition.
- Select this candidate to save the metadata to the Bookorbit database.
- The local database will now have the audiobook's isbn13 saved alongside the physical book's pageCount.
Expected vs actual behavior
Expected Behavior: The metadata fetcher should filter or rank editions by format and closeness to the local file's known page count. Furthermore, audiobooks should not inherit the generic book.pages value so that they correctly display as having no pages in the UI, making it obvious to the user that they are not physical books. Bookorbit should ideally present the single best-matching physical/ebook edition.
Actual Behavior: Bookorbit simply iterates over all editions and uses the pageCount: edition.pages ?? book.pages fallback in hardcover.mapper.ts. The automated pipeline then blindly selects the first candidate returned, which frequently happens to be the audiobook with a hijacked page count.
Your setup
Bookorbit version: latest
Deployment: Docker
OS: Unraid
Browser: Firefox 151.0.4
Relevant logs (optional)
Screenshots (optional)
No response
Before submitting
What went wrong?
When investigating Bug#333 I came across another issue, but with the Metadata system. When Bookorbit fetches metadata from Hardcover (e.g. when searching for a book to add to the library), it can select an audiobook edition as the primary result, despite the file being an epub. This results in an odd metadata entry saved to the Bookorbit database: it displays a physical page count (e.g., 1243 pages) but silently stores the audiobook's ISBN. Consequently, any future Hardcover integration syncs perfectly match against the wrong edition, an audiobook in this instance.
Note: I am not a coder, but I've dabbled with using LLM for solving simple personal software needs and some of the specific technical details identified below are from it.
Steps to reproduce
Expected vs actual behavior
Expected Behavior: The metadata fetcher should filter or rank editions by format and closeness to the local file's known page count. Furthermore, audiobooks should not inherit the generic book.pages value so that they correctly display as having no pages in the UI, making it obvious to the user that they are not physical books. Bookorbit should ideally present the single best-matching physical/ebook edition.
Actual Behavior: Bookorbit simply iterates over all editions and uses the pageCount: edition.pages ?? book.pages fallback in hardcover.mapper.ts. The automated pipeline then blindly selects the first candidate returned, which frequently happens to be the audiobook with a hijacked page count.
Your setup
Bookorbit version: latest
Deployment: Docker
OS: Unraid
Browser: Firefox 151.0.4
Relevant logs (optional)
Screenshots (optional)
No response
Before submitting