Audiobookshelf support (chapters, resume position, self-hosted alternative to paid apps)

[jpdexter101-lang]

I use audiobooks a lot and right now the only good option for listening from a self-hosted server is Bookcamp, and it only talks to Plex, and it's a paid subscription (~$1-2/month) for things like cross-device resume position and offline downloads. I'd love to see that same experience built into Linthra instead, backed by Audiobookshelf specifically, free and fully self-hosted end to end.

I don't want this to land as one giant PR. Same as the Linux port, I'd rather it come in as a few small, reviewable pieces.

What I want

• Audiobookshelf as a real provider (connection, auth, library browsing)
• Chapters as a first-class concept, not just long tracks, with a player that works just as well when a file has none
• Multi-file books play straight through automatically, no tapping "next" between files
• Real resume position that syncs across devices
• Adjustable playback speed that also follows you across devices, not just a local toggle that resets per phone
• Bookmarks, separate from resume position, since a listener deliberately marking a spot is a different thing from the app remembering where they stopped
• Sleep timer, chapter navigation
• Offline downloads

Suggested PRs

1. Connection + library browsing — server URL, auth, HTTP client, list the library. No playback yet.
2. Domain model + chapters + local playback — add chapters to the data model, get a book playing with chapter-aware seeking. Multi-file books load as one continuous queue so playback auto-advances between files with no manual tap, same as the existing queue behavior for music. Resume position local-only for now.
3. Cross-device sync — resume position and playback speed, both synced as Audiobookshelf's own server-side user settings, not just local state.
4. Audiobook player UI — speed control, chapter list/jump when available, always backed by a time scrubber and skip buttons so a chapterless file still has a real player, since plenty of real-world files (especially single-file torrent rips) have no embedded chapter metadata at all and Audiobookshelf's own scanner can't build chapters from just one unmarked file.
5. Bookmarks — Audiobookshelf already has real bookmark endpoints server-side, separate from resume position.
6. Offline downloads — may be able to lean on existing offline-cache infra, worth checking once in the code.

Important

• Don't touch the existing music providers or their UI
• Keep this behind its own clear seam, same as the Jellyfin/Subsonic/Plex providers are
• First milestone is just Scaffold Echora foundation: architecture, theming, and navigation #1, working and reviewable on its own

[TheZupZup]

@jpdexter101-lang This is awesome, thank you for taking the time to break it down like this.

I really like the approach of keeping it as small, reviewable PRs instead of one huge Audiobookshelf implementation. The separation from the existing music providers is also exactly what I want.

You have my full green light for milestone #1. Go for it! I'm really looking forward to seeing where this goes.

And thanks again for putting so much thought into this!

[jpdexter101-lang]

Quick question before I get into milestone 2: the Audiobookshelf provider needs gapless playback across multiple audio files for a single book (chapters can span across a file split, so a gap between files would be audible mid-sentence). Linthra's current queue doesn't do this, it's built for music where a gap between tracks is fine.

I'd like to use just_audio's ConcatenatingAudioSource for this, scoped entirely to the Audiobookshelf playback path, not touching the existing music queue/auto-advance logic at all. Wanted to check that's a pattern you're fine with before I build on it, since it'd be new to the codebase. Let me know if you'd rather see a different approach.

[TheZupZup]

@jpdexter101-lang Yep, that approach sounds good to me. Keeping ConcatenatingAudioSource scoped to Audiobookshelf and leaving the existing music queue/auto-advance logic untouched is exactly what I’d prefer for milestone 2.

Just make sure we have coverage for file-to-file chapter transitions and resume/seek behavior so we know the audiobook path stays gapless without affecting normal music playback. Go for it 👍

[jpdexter101-lang]

Question about where Audiobooks should live in the nav before I go further into milestone 4.

Right now it's a 5th sub-tab inside the Library screen, next to Songs/Albums/Artists/Folders. That's already causing problems. I had to make the tab bar scrollable to fit five labels. I added a queueEntireList flag so tapping a book doesn't queue the rest of the library behind it like a song would. A book isn't a track. It has resume position, chapters, and people browse it by series and author, not the way the current screen is built.

Proposed fix: give Audiobooks its own spot in the bottom nav, a peer to Library/Playlists/Downloads/Settings instead of a sub-tab.

• Rename "Library" to "Music." No functional change, it already only shows Songs/Albums/Artists/Folders once Audiobooks moves out.
• Remove the Audiobooks sub-tab from that screen.
• Add a new "Audiobooks" destination next to it, with its own screen: continue listening, browse by series, browse by author, a to-listen list you curate yourself.
• Playlists, Downloads, Settings stay exactly as they are.

One more thing worth flagging: making this a permanent nav slot means anyone who hasn't connected an Audiobookshelf server sees an empty tab. I'd make it conditional, it only shows up once a server's actually connected, same idea as apps that only show a Downloads tab once you have something downloaded. Keeps the win for people who use it without adding a dead tab for people who don't.

It's a small nav change. One rename, one tab removed, one tab added, one of them conditional. Nothing else in the app changes shape. It does touch shared nav chrome though, so I want your take before I build it out: does this match how you'd want audiobooks positioned, or is there a different direction you'd rather I take?

[TheZupZup]

Thanks for checking before going further. I agree with the core direction here: audiobooks have grown far enough away from the music model that they should have their own dedicated surface instead of being forced into Songs/Albums/Artists/Folders.

I'm good with:

• renaming Library to Music
• removing Audiobooks from the Music tabs
• giving Audiobooks its own destination and screen

I would prefer the Audiobooks destination to stay stable rather than appear/disappear based on connection state. If no Audiobookshelf server is configured, that screen can simply offer a clear connection/setup state. That keeps navigation predictable and also makes the feature discoverable.

I also want to keep this next PR very tightly scoped. Please make the navigation move itself one reviewable change: rename Music, move Audiobooks out, add the destination, and preserve the existing audiobook functionality. Things like Continue Listening, Series, Authors, and To Listen can follow in separate PRs.

One additional maintainer requirement given the recent repository-integrity incident: please start this work from a fresh branch based directly on current main, without reusing or merging history from any of the affected branches. Keep the diff limited to files genuinely required for this milestone, with no editor configuration, generated assets, tooling files, or unrelated cleanup included.

This isn't an accusation about anyone's intent. I just need to be stricter about branch provenance and scope going forward, and I'll be reviewing the full commit history as well as the final diff before merge.

The Audiobookshelf work itself is still welcome, and I appreciate you asking before changing shared navigation. 👍