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

marxjohnson commented 1 month ago

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

nichwall commented 1 month ago

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.

marxjohnson commented 1 month ago

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.

nichwall commented 1 month ago

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.

vachekcz commented 1 week ago

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 1 week ago

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 :)

advplyr commented 1 week ago

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.

vachekcz commented 1 week ago

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

advplyr commented 1 week ago

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.

marxjohnson commented 1 week ago

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.

vachekcz commented 1 week ago

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.

advplyr / audiobookshelf-app