Seperate Book and Audiobook Libraries

[BotBlake]

Separate Book and Audiobook Libraries

Currently, Jellyfin uses a single library type for both books and audiobooks. This creates several challenges and inefficiencies for both server management and client-side experiences.

First of all, audiobooks and books are not the same and therefore should not be forced to be handled in the same way!
We already acknowledge this principle in other areas—take TV shows and movies, for example. Yes, both have actors and both are video content, but their differences are significant enough that we handle them separately. The same logic applies here: audiobooks and books might both represent literature, but their formats, consumption methods, and metadata needs diverge significantly.

For instance:

• Audiobooks are audio files meant for listening, requiring playback controls, speed adjustments, and chapter navigation.
• Books, on the other hand, are text-based, meant for reading, with features like bookmarks, font adjustments, and annotations.

It’s worth clarifying that this discussion is not about whether Jellyfin should continue to support books or not. Instead, it focuses solely on the structural improvement of separating book and audiobook libraries. Regardless of the ongoing debate about the future of book support, separating these libraries is a logical first step toward improving the user experience for both books and audiobooks.

To explain why this separation makes sense, we can divide the discussion into two main categories:

Improvements: Why Separating Libraries Makes Sense

Separating book and audiobook libraries would yield several benefits:

1. Easier Audiobook Handling
   Audiobooks share many similarities with music libraries, making it easier to adapt existing playback and metadata handling code:

   • Features like track navigation, progress saving, and playlist support could be reused.
   • Metadata fields such as chapters, album (book title), and artist (author) closely parallel those used in music libraries.
   • Audiobooks often include additional metadata like narrators, multiple versions (e.g., abridged vs. unabridged), or chapter breakdowns.

2. Tailored Book and Audiobook Experiences
   By separating libraries, each media type can focus on its unique needs and use cases. For audiobooks, playback and audio-specific metadata can be prioritized. For books, libraries will focus on organization and filtering without having to account for playback-related features that do not apply to text content.

Current Issues: Why the Current Behavior Is suboptimal

1. Impractical for TV and Other Clients
   While books could theoretically be supported on a TV, it’s not a practical use case. Reading a book on a large screen with a remote control is cumbersome and unlikely to be a priority for most users. As a result:

   • Many clients (e.g., viv and finamp) already filter out book items from the combined library type, effectively making it function as an audiobook-only library.
   • Separating books and audiobooks would eliminate the need for such filtering and allow clients to focus on tailored support for each type.

2. Confusing Library Structure
   The current recommendation is to place both books and audiobooks into a single library, divided into subfolders like "Books" and "Audiobooks." However, this approach has significant downsides:

   • Users are forced to navigate through a "folder-like" structure to select the content type they want.
   • Many clients don’t even display this folder structure, further complicating access or implementation.
     Libraries are meant to help users quickly access content—not to require additional sub-navigation. Forcing this structure on the books library type contradicts the purpose of libraries.

3. Misaligned with User Behavior
   Many users already create separate Books-type libraries for books and audiobooks, bypassing the recommended structure entirely. If users are effectively separating their libraries themselves, it makes little sense to force developers and clients to work harder to accommodate the combined library model.

[brys0]

Perhaps the original idea related to adding "books" was so you could have both the text for a book, and the audio/read along for a book in the same place?
However considering we already have a way for shows/other media to reference related media it is confusing why the two: books, and audio-books are part of the same library type. Logistically speaking this feels similar to the issues people have with mixing both shows and movie under one folder / library.

[sjorge]

Having them separate makes sense to me, apps might only want to focus on say audio. We already have many music only apps.

[1hitsong]

YES! For the love of everyone's sanity, audiobooks and books should have their own library types!