[Android] Support for mp3 index seeking #499

New Issue

2026-04-24T23:26:21+02:00

adam commented

2026-04-24 23:26:21 +02:00

Originally created by @Mega-Volti on GitHub (Mar 22, 2023).

Steps to reproduce

Listen to audiobook with a single, large mp3 file
Seek or pause playback and start it up again

Expected behaviour

Playback should re-start where it was paused or +- 10 seconds from the seek position

Actual behaviour

The playback position is off a little bit, sometimes only a couple of seconds, sometimes even a few minutes, time discrepancy seems to increase depending on length of listening session (it might be a rounding error when saving the playback time?)
I haven't observed this issue when playing books split into multiple, smaller audio files
The issue only occurs when playing with the Android app, not when using the web interface.
The issue occurs regardless of playing an audiobook stored locally, or when using the app and streaming.
Weirdly, after seeking back and forth a bit, a particular section in the audiobook I use for testing settled on 1:10:05 for the exact sentence I was using for the test. Then, switching to the web interface and searching the same position, the very same sentence was spoken at 1:09:35 instead.

Environment data

Audiobookshelf Version: v2.2.17

Android App? v0.9.63-beta
iOS App?

Originally created by @Mega-Volti on GitHub (Mar 22, 2023). ### Steps to reproduce 1. Listen to audiobook with a single, large mp3 file 2. Seek or pause playback and start it up again ### Expected behaviour - Playback should re-start where it was paused or +- 10 seconds from the seek position ### Actual behaviour - The playback position is off a little bit, sometimes only a couple of seconds, sometimes even a few minutes, time discrepancy seems to increase depending on length of listening session (it might be a rounding error when saving the playback time?) - I haven't observed this issue when playing books split into multiple, smaller audio files - The issue only occurs when playing with the Android app, not when using the web interface. - The issue occurs regardless of playing an audiobook stored locally, or when using the app and streaming. - Weirdly, after seeking back and forth a bit, a particular section in the audiobook I use for testing settled on 1:10:05 for the exact sentence I was using for the test. Then, switching to the web interface and searching the same position, the very same sentence was spoken at 1:09:35 instead. ### Environment data Audiobookshelf Version: v2.2.17 - [x] Android App? v0.9.63-beta - [ ] iOS App?

adam added the enhancement label 2026-04-24 23:26:21 +02:00

adam closed this issue

2026-04-24 23:26:21 +02:00

adam commented

2026-04-24 23:26:22 +02:00

@hobesman commented on GitHub (Mar 22, 2023):

Is this happening with all of your mp3 files? Or just certain ones?

I experienced a sort of similar issue with an audiobook that was encoded weirdly. I reencoded it with VLC and it worked better after that.

@hobesman commented on GitHub (Mar 22, 2023): Is this happening with all of your mp3 files? Or just certain ones? I experienced a sort of similar issue with an audiobook that was encoded weirdly. I reencoded it with VLC and it worked better after that.

adam commented

2026-04-24 23:26:23 +02:00

@Mega-Volti commented on GitHub (Mar 22, 2023):

The issue only occurs when using the Android app, not when playing via the Web interface.

If it were a file encoding issue, then it would affect the web interface as well. Since it does not, I conclude that it has to be a bug in the app.

My best guess is that the playback position is saved differently in the server version (used to play via the web interface) and the Android app, and that whatever method is used in the app is less precise than the method used for the server.

@Mega-Volti commented on GitHub (Mar 22, 2023): The issue only occurs when using the Android app, not when playing via the Web interface. If it were a file encoding issue, then it would affect the web interface as well. Since it does not, I conclude that it has to be a bug in the app. My best guess is that the playback position is saved differently in the server version (used to play via the web interface) and the Android app, and that whatever method is used in the app is less precise than the method used for the server.

adam commented

2026-04-24 23:26:24 +02:00

@Mega-Volti commented on GitHub (May 20, 2023):

This is still happening in the latest version. Not with all files, it seems to only occur when playing an audiobook with a single, long mp3 file.
Started a new one the other day and the issue persists: The playback position in the Android player is off regularly when seeking or pausing and resuming. On the other hand, when using the web interface (either on PC or the Android phone), everything works perfectly and there is no issue with the playback position whatsoever.
Which means the mp3 file can't be to blame, somehow the Android app is determining the playback position differently than the web interface and the former is having some sort of bug.

@Mega-Volti commented on GitHub (May 20, 2023): This is still happening in the latest version. Not with all files, it seems to only occur when playing an audiobook with a single, long mp3 file. Started a new one the other day and the issue persists: The playback position in the Android player is off regularly when seeking or pausing and resuming. On the other hand, when using the web interface (either on PC or the Android phone), everything works perfectly and there is no issue with the playback position whatsoever. Which means the mp3 file can't be to blame, somehow the Android app is determining the playback position differently than the web interface and the former is having some sort of bug.

adam commented

2026-04-24 23:26:24 +02:00

@DebrodeD commented on GitHub (May 24, 2023):

This issue is happening to me as well across all of my mp3 files, on multiple android devices using the android app. It does not happen in the webplayer and I'm testing whether it happens with m4b files or not, but I'm guessing not.

@DebrodeD commented on GitHub (May 24, 2023): This issue is happening to me as well across all of my mp3 files, on multiple android devices using the android app. It does not happen in the webplayer and I'm testing whether it happens with m4b files or not, but I'm guessing not.

adam commented

2026-04-24 23:26:26 +02:00

@Mega-Volti commented on GitHub (Jun 16, 2023):

Update:

I loaded up the very same audiobook (local file as downloaded by the ABS Android app) into AntennaPod. At first I thought it plays perfectly there, but after longer listening sessions I did actually notice offsets within AntennaPod as well. They seem smaller than in ABS, though, but that might just be random.

I also loaded the file up in VLC (for Android) and it plays perfectly fine there. No offsets whatsoever.

So whatever ABS' mp3 player does, AntennaPod's mp3 player seems to have similar issues but VLC doesn't. Maybe that helps with pinpointing the bug.

Addtionally: This seems to occur with pretty much all mp3 files when using the Android app. I have noticed it with audiobooks split into smaller files, although it is very hard to pinpoint there since the offset is usually only a few seconds - but it does exist and it is reproducible once I knew what I was looking for. The longer the mp3 file is, the more pronounced (and easier to find) the offset, which is why at first I only noticed it with single file mp3 audiobooks.

@Mega-Volti commented on GitHub (Jun 16, 2023): Update: I loaded up the very same audiobook (local file as downloaded by the ABS Android app) into AntennaPod. At first I thought it plays perfectly there, but after longer listening sessions I did actually notice offsets within AntennaPod as well. They seem smaller than in ABS, though, but that might just be random. I also loaded the file up in VLC (for Android) and it plays perfectly fine there. No offsets whatsoever. So whatever ABS' mp3 player does, AntennaPod's mp3 player seems to have similar issues but VLC doesn't. Maybe that helps with pinpointing the bug. Addtionally: This seems to occur with pretty much all mp3 files when using the Android app. I have noticed it with audiobooks split into smaller files, although it is very hard to pinpoint there since the offset is usually only a few seconds - but it does exist and it is reproducible once I knew what I was looking for. The longer the mp3 file is, the more pronounced (and easier to find) the offset, which is why at first I only noticed it with single file mp3 audiobooks.

adam commented

2026-04-24 23:26:26 +02:00

@advplyr commented on GitHub (Jun 17, 2023):

I was able to get the sample mp3 file seeking correctly by setting FLAG_ENABLE_INDEX_SEEKING in exoplayer: https://developer.android.com/guide/topics/media/exoplayer/customization#customizing-extractor-flags

Until I understand this better or some other solution comes along we can add a device setting to use this flag.

@advplyr commented on GitHub (Jun 17, 2023): I was able to get the sample mp3 file seeking correctly by setting `FLAG_ENABLE_INDEX_SEEKING` in exoplayer: https://developer.android.com/guide/topics/media/exoplayer/customization#customizing-extractor-flags Until I understand this better or some other solution comes along we can add a device setting to use this flag.

adam commented

2026-04-24 23:26:27 +02:00

@advplyr commented on GitHub (Jun 17, 2023):

Setting is added for next release.

The view more links to https://exoplayer.dev/troubleshooting.html#why-is-seeking-inaccurate-in-some-mp3-files

@advplyr commented on GitHub (Jun 17, 2023): Setting is added for next release. ![image](https://github.com/advplyr/audiobookshelf-app/assets/67830747/29100cfc-e19f-4efc-bb28-cc7685b96739) The view more links to https://exoplayer.dev/troubleshooting.html#why-is-seeking-inaccurate-in-some-mp3-files

adam commented

2026-04-24 23:26:27 +02:00

@advplyr commented on GitHub (Jun 25, 2023):

Added in v0.9.65-beta

@advplyr commented on GitHub (Jun 25, 2023): Added in [v0.9.65-beta](https://github.com/advplyr/audiobookshelf-app/releases/tag/v0.9.65-beta)

adam commented

2026-04-24 23:26:28 +02:00

@Mega-Volti commented on GitHub (Jul 16, 2023):

Sadly, this is not quite fixed.

The app setting does not seem to take: I can activate it in the settings, but when closing the app and opening the settings again, it is deactivated again.

Additionally, the seek issue described above is still occuring (which makes sense since the new setting doesn't seem to work).

@Mega-Volti commented on GitHub (Jul 16, 2023): Sadly, this is not quite fixed. The app setting does not seem to take: I can activate it in the settings, but when closing the app and opening the settings again, it is deactivated again. Additionally, the seek issue described above is still occuring (which makes sense since the new setting doesn't seem to work).

adam commented

2026-04-24 23:26:28 +02:00

@advplyr commented on GitHub (Sep 19, 2023):

The setting is fixed in 0.9.66 in that it will show that it is applied. It was getting applied before it just wasn't showing that it was. Let me know how it goes

@advplyr commented on GitHub (Sep 19, 2023): The setting is fixed in 0.9.66 in that it will show that it is applied. It was getting applied before it just wasn't showing that it was. Let me know how it goes

adam referenced this issue

2026-04-24 23:58:27 +02:00

[PR #499] [MERGED] Metadata Table Alignment #1438

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: starred/audiobookshelf-app#499