[PR #1763] [MERGED] Enable constant bitrate seeking to fix AAC seek reset in ExoPlayer #1687

New Issue

2026-04-25T00:00:36+02:00

adam commented

2026-04-25 00:00:36 +02:00

📋 Pull Request Information

Original PR: https://github.com/advplyr/audiobookshelf-app/pull/1763
Author: @randomdude583
Created: 12/24/2025
Status: ✅ Merged
Merged: 2/1/2026
Merged by: @advplyr

Base: master ← Head: fix/android-aac-seek-issue

📝 Commits (1)

3f0bc74 Enable constant bitrate seeking to fix AAC seek reset in ExoPlayer

📊 Changes

1 file changed (+4 additions, -0 deletions)

View changed files

📝 android/app/src/main/java/com/audiobookshelf/app/player/PlayerNotificationService.kt (+4 -0)

📄 Description

Brief summary

Fixes an Android issue where seeking in certain AAC audio files would reset playback to the beginning of the file. This could also occur when resuming playback partway through a file after the app had been inactive, which effectively behaved the same as a seek.

Which issue is fixed?

Fixes #1308

Pull Request Type

Android app

In-depth Description

On Android, audiobookshelf uses ExoPlayer for audio playback. For some AAC audio files, ExoPlayer is unable to derive a reliable seek map. When a seek is requested in these cases, ExoPlayer may “adjust” the seek back to position 0, causing playback to jump to the beginning after buffering.

This behavior has been observed with certain AAC files and does not reproduce in the web player, which uses the browser’s media stack. Other formats (such as MP3) generally do not exhibit this issue.

This change enables ExoPlayer’s constant-bitrate seeking mode on the DefaultExtractorsFactory for progressive playback (both local and direct HTTP sources). This allows ExoPlayer to perform approximate seeking for media where a seek map is unavailable, preventing the seek-to-start behavior while preserving normal behavior for formats that provide proper indexing.

Notes:

Seeking becomes approximate for affected AAC files, which is expected for this fallback.
No regressions were observed with MP3 or other indexed formats.
HLS playback is unaffected.

How have you tested this?

I tested this using the TrueNAS Tech Talk podcast (RSS feed: https://www.truenas.com/feed/podcast/truenas-welcome-to-the-open-storage-era/), which publishes episodes encoded as AAC and reliably reproduces the issue.

Testing included:

Seeking using the playhead
Using skip forward/back controls
Pausing playback, exiting the app, and later resuming playback

These tests were performed both while streaming episodes from the server and when playing episodes downloaded locally.

Additional testing was done with audiobooks encoded as m4b and mp3, and no regressions were observed.

Screenshots

_{🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.}

## 📋 Pull Request Information **Original PR:** https://github.com/advplyr/audiobookshelf-app/pull/1763 **Author:** [@randomdude583](https://github.com/randomdude583) **Created:** 12/24/2025 **Status:** ✅ Merged **Merged:** 2/1/2026 **Merged by:** [@advplyr](https://github.com/advplyr) **Base:** `master` ← **Head:** `fix/android-aac-seek-issue` --- ### 📝 Commits (1) - [`3f0bc74`](https://github.com/advplyr/audiobookshelf-app/commit/3f0bc74c21e5de982836a5c1786955238893f83b) Enable constant bitrate seeking to fix AAC seek reset in ExoPlayer ### 📊 Changes **1 file changed** (+4 additions, -0 deletions) <details> <summary>View changed files</summary> 📝 `android/app/src/main/java/com/audiobookshelf/app/player/PlayerNotificationService.kt` (+4 -0) </details> ### 📄 Description  ## Brief summary  Fixes an Android issue where seeking in certain AAC audio files would reset playback to the beginning of the file. This could also occur when resuming playback partway through a file after the app had been inactive, which effectively behaved the same as a seek. ## Which issue is fixed?  Fixes [#1308](https://github.com/advplyr/audiobookshelf-app/issues/1308) ## Pull Request Type  Android app ## In-depth Description  On Android, audiobookshelf uses ExoPlayer for audio playback. For some AAC audio files, ExoPlayer is unable to derive a reliable seek map. When a seek is requested in these cases, ExoPlayer may “adjust” the seek back to position 0, causing playback to jump to the beginning after buffering. This behavior has been observed with certain AAC files and does not reproduce in the web player, which uses the browser’s media stack. Other formats (such as MP3) generally do not exhibit this issue. This change enables ExoPlayer’s constant-bitrate seeking mode on the DefaultExtractorsFactory for progressive playback (both local and direct HTTP sources). This allows ExoPlayer to perform approximate seeking for media where a seek map is unavailable, preventing the seek-to-start behavior while preserving normal behavior for formats that provide proper indexing. Notes: - Seeking becomes approximate for affected AAC files, which is expected for this fallback. - No regressions were observed with MP3 or other indexed formats. - HLS playback is unaffected. ## How have you tested this?  I tested this using the TrueNAS Tech Talk podcast (RSS feed: https://www.truenas.com/feed/podcast/truenas-welcome-to-the-open-storage-era/), which publishes episodes encoded as AAC and reliably reproduces the issue. Testing included: - Seeking using the playhead - Using skip forward/back controls - Pausing playback, exiting the app, and later resuming playback These tests were performed both while streaming episodes from the server and when playing episodes downloaded locally. Additional testing was done with audiobooks encoded as m4b and mp3, and no regressions were observed. ## Screenshots  --- <sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>

adam added the pull-request label 2026-04-25 00:00:36 +02:00

adam closed this issue

2026-04-25 00:00:37 +02:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: starred/audiobookshelf-app#1687