[Bug]: Large audiobooks not resuming in the correct position, not seeking correctly with direct playback #1061

New Issue

2026-04-24T23:47:22+02:00

adam commented

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

Originally created by @marxjohnson on GitHub (Oct 18, 2024).

What was the Problem?

When I am playing a large audiobook (in this case Critical Role, which has 2-4 hour chapters), the book starts playing in Direct mode but does not resume from the previous position. Seeking does not work correctly, it often jumps back to the previous position, and the position of the playback slider does not match with the position in the chapter.

After trying to seek several times, it switches to Transcode, after which the slider matches the position in the chapter and seeking works correctly.

This sounds similar to #227 which is supposedly fixed so it may not be possible to get Direct playback to work all the time on very large files, but if there was a per-book option to always use Transcode that would solve the problem for me.

This problem does not occur with smaller books.

The attached video demonstrates the problem.

https://github.com/user-attachments/assets/f1617a92-1e2a-4277-b110-1b23fad94d6e

Steps to Reproduce the Issue

Add a very large book to your library, e.g. Critical Role: https://critrole.com/campaign-1-podcast/
Open the book in the Android app, and start playing.
Pause playback and create a bookmark. Make a note of the playback position.
Close the app and reopen it.
Start playing the book again.
The playback is not in the position it was left, and seeking does not work.

What was Expected?

The playback should be in the position it was left.

Phone Model

Pixel 6a

Phone OS

Android 14 (Stock)

Audiobookshelf App Version

Android App - 0.9.76

Installation Source

Google Play Store

Additional Notes

No response

Originally created by @marxjohnson on GitHub (Oct 18, 2024). ### What was the Problem? When I am playing a large audiobook (in this case Critical Role, which has 2-4 hour chapters), the book starts playing in Direct mode but does not resume from the previous position. Seeking does not work correctly, it often jumps back to the previous position, and the position of the playback slider does not match with the position in the chapter. After trying to seek several times, it switches to Transcode, after which the slider matches the position in the chapter and seeking works correctly. This sounds similar to #227 which is supposedly fixed so it may not be possible to get Direct playback to work all the time on very large files, but if there was a per-book option to always use Transcode that would solve the problem for me. This problem does not occur with smaller books. The attached video demonstrates the problem. https://github.com/user-attachments/assets/f1617a92-1e2a-4277-b110-1b23fad94d6e ### Steps to Reproduce the Issue - Add a very large book to your library, e.g. Critical Role: https://critrole.com/campaign-1-podcast/ - Open the book in the Android app, and start playing. - Pause playback and create a bookmark. Make a note of the playback position. - Close the app and reopen it. - Start playing the book again. - The playback is not in the position it was left, and seeking does not work. ### What was Expected? The playback should be in the position it was left. ### Phone Model Pixel 6a ### Phone OS Android 14 (Stock) ### Audiobookshelf App Version Android App - 0.9.76 ### Installation Source Google Play Store ### Additional Notes _No response_

adam added the bug label 2026-04-24 23:47:22 +02:00

adam closed this issue

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

adam commented

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

@nichwall commented on GitHub (Oct 18, 2024):

Is there a reason you are using the book library for podcasts instead of a podcast library?

Though, this is definitely an easy way to reproduce the "extra big" books (10+ GB) people have issues with.

@nichwall commented on GitHub (Oct 18, 2024): Is there a reason you are using the book library for podcasts instead of a podcast library? Though, this is definitely an easy way to reproduce the "extra big" books (10+ GB) people have issues with.

adam commented

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

@marxjohnson commented on GitHub (Oct 18, 2024):

In this case, the podcast feed doesn't include every chapter, and does include some other stuff, so I downloaded them from the website and put them in my audiobook library.

@marxjohnson commented on GitHub (Oct 18, 2024): In this case, the podcast feed doesn't include every chapter, and does include some other stuff, so I downloaded them from the website and put them in my audiobook library.

adam commented

2026-04-24 23:47:25 +02:00

@nichwall commented on GitHub (Oct 18, 2024):

That's fair. You can still just put each file in the podcast folder, it doesn't need to be downloaded by ABS (that was the original design, having ABS download files was added later).

There are several QOL feature requests for podcasts in the app/web client, so wasn't sure if it was due to a specific feature missing or not knowing about the podcast library.

@nichwall commented on GitHub (Oct 18, 2024): That's fair. You can still just put each file in the podcast folder, it doesn't need to be downloaded by ABS (that was the original design, having ABS download files was added later). There are several QOL feature requests for podcasts in the app/web client, so wasn't sure if it was due to a specific feature missing or not knowing about the podcast library.

adam commented

2026-04-24 23:47:25 +02:00

@vachekcz commented on GitHub (Nov 10, 2024):

I have exactly the same problem.
When I upload an audiobook of approximately 500 MB and start playing it, it works fine. However, as soon as I skip ahead (without letting it play through on its own), it freezes and can’t be played anymore, only restarted from the beginning.

@vachekcz commented on GitHub (Nov 10, 2024): I have exactly the same problem. When I upload an audiobook of approximately 500 MB and start playing it, it works fine. However, as soon as I skip ahead (without letting it play through on its own), it freezes and can’t be played anymore, only restarted from the beginning.

adam commented

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

@vachekcz commented on GitHub (Nov 10, 2024):

I just resolved it, and I’ll show you how (the original audio was downloaded through some YouTube downloader).

The file looked like this:

file Astrofyzika.mp3
Astrofyzika.mp3: ISO Media, MPEG v4 system, Dynamic Adaptive Streaming over HTTP

I tried converting it to just 128k with this command:

ffmpeg -i "Astrofyzika.mp3" -acodec libmp3lame -b:a 128k "converted_astrophysics.mp3"
The result was:

file converted_astrophysics.mp3
converted_astrophysics.mp3: Audio file with ID3 version 2.4.0, contains: MPEG ADTS, layer III, v1, 128 kbps, 44.1 kHz, Stereo

and now, all works fine :)

@vachekcz commented on GitHub (Nov 10, 2024): I just resolved it, and I’ll show you how (the original audio was downloaded through some YouTube downloader). The file looked like this: `file Astrofyzika.mp3 ` `Astrofyzika.mp3: ISO Media, MPEG v4 system, Dynamic Adaptive Streaming over HTTP ` I tried converting it to just 128k with this command: `ffmpeg -i "Astrofyzika.mp3" -acodec libmp3lame -b:a 128k "converted_astrophysics.mp3" ` The result was: `file converted_astrophysics.mp3 ` `converted_astrophysics.mp3: Audio file with ID3 version 2.4.0, contains: MPEG ADTS, layer III, v1, 128 kbps, 44.1 kHz, Stereo` and now, all works fine :)

adam commented

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

@advplyr commented on GitHub (Nov 11, 2024):

Thanks for following up. Every time the "not correct position" has been reported it is a VBR mp3 file. I always wonder where these are coming from.
As far as I know there is nothing we can do about these other than re-encode them. We may build in a tool that does this since it is a simple ffmpeg command and a common enough issue that causes bug reports.

@advplyr commented on GitHub (Nov 11, 2024): Thanks for following up. Every time the "not correct position" has been reported it is a VBR mp3 file. I always wonder where these are coming from. As far as I know there is nothing we can do about these other than re-encode them. We may build in a tool that does this since it is a simple ffmpeg command and a common enough issue that causes bug reports.

adam commented

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

@vachekcz commented on GitHub (Nov 11, 2024):

That would be really great if you could create an internal checker that could report this or, ideally, convert it directly (in the background).
thx

@vachekcz commented on GitHub (Nov 11, 2024): That would be really great if you could create an internal checker that could report this or, ideally, convert it directly (in the background). thx

adam commented

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

@advplyr commented on GitHub (Nov 11, 2024):

I'm not sure how to check for it with ffmpeg without decoding a portion of the file which we wouldn't want to do on every audio file during scans. That would add a lot of overhead.
If anyone comes across this and knows a good method to do this with ffmpeg that doesn't require an additional dependency let me know.

@advplyr commented on GitHub (Nov 11, 2024): I'm not sure how to check for it with ffmpeg without decoding a portion of the file which we wouldn't want to do on every audio file during scans. That would add a lot of overhead. If anyone comes across this and knows a good method to do this with ffmpeg that doesn't require an additional dependency let me know.

adam commented

2026-04-24 23:47:29 +02:00

@marxjohnson commented on GitHub (Nov 11, 2024):

This is the file I'm currently having trouble with:

file C2E45\ The\ Stowaway.mp3 
C2E45 The Stowaway.mp3: Audio file with ID3 version 2.3.0, contains: MPEG ADTS, layer III, v1, 48 kbps, 44.1 kHz, JntStereo

I've worked around the issue for now by adding this to a Podcast library instead, per @nichwall's suggestion. Since you can download a individual episodes/chapters at a time with podcasts and play locally, this works around the streaming issue.

@marxjohnson commented on GitHub (Nov 11, 2024): This is the file I'm currently having trouble with: ``` file C2E45\ The\ Stowaway.mp3 C2E45 The Stowaway.mp3: Audio file with ID3 version 2.3.0, contains: MPEG ADTS, layer III, v1, 48 kbps, 44.1 kHz, JntStereo ``` I've worked around the issue for now by adding this to a Podcast library instead, per @nichwall's suggestion. Since you can download a individual episodes/chapters at a time with podcasts and play locally, this works around the streaming issue.

adam commented

2026-04-24 23:47:29 +02:00

@vachekcz commented on GitHub (Nov 12, 2024):

I'm not sure how to check for it with ffmpeg without decoding a portion of the file which we wouldn't want to do on every audio file during scans. That would add a lot of overhead. If anyone comes across this and knows a good method to do this with ffmpeg that doesn't require an additional dependency let me know.

I think it would be great to establish a certain “standard” for recommended quality. If the content is in another format, there could be an on/off option in the admin/settings that would standardize it accordingly (process in background, replace original file with new one).

When I download books from Audiolibrix or other large audiobook providers, they also always have the same quality and file type. Right now, it’s possible to have different versions here, which causes issues for users.

I believe even MP3 at 128 kbps would be more than sufficient for audiobooks—nobody needs hi-fi quality. :)

This is just my opinion; I don’t know how to program it, but it seems like a good solution to standardize it.

@vachekcz commented on GitHub (Nov 12, 2024): > I'm not sure how to check for it with ffmpeg without decoding a portion of the file which we wouldn't want to do on every audio file during scans. That would add a lot of overhead. If anyone comes across this and knows a good method to do this with ffmpeg that doesn't require an additional dependency let me know. I think it would be great to establish a certain “standard” for recommended quality. If the content is in another format, there could be an on/off option in the admin/settings that would standardize it accordingly (process in background, replace original file with new one). When I download books from Audiolibrix or other large audiobook providers, they also always have the same quality and file type. Right now, it’s possible to have different versions here, which causes issues for users. I believe even MP3 at 128 kbps would be more than sufficient for audiobooks—nobody needs hi-fi quality. :) This is just my opinion; I don’t know how to program it, but it seems like a good solution to standardize it.

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: starred/audiobookshelf-app#1061