mirror of
https://github.com/advplyr/audiobookshelf-app.git
synced 2026-07-26 14:38:39 +02:00
[Bug]: App crashes when downloading an audiobook #1196
Assignees
adam (Adam Melkus)
Clear assignees
adam (Adam Melkus)
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: starred/audiobookshelf-app#1196
Reference in New Issue
Block a user
Originally created by @Zibbp on GitHub (Apr 24, 2025).
I have verified that the bug is not already awaiting release
Yes
What was the Problem?
Clicking the "download" button for an audiobook crashes the app when attempting to download.
Steps to Reproduce the Issue
What was Expected?
The audiobook should download without crashing.
Phone Model
Samsung Galaxy S22
Phone OS
Android 14
Audiobookshelf App Version
Android App - 0.9.79
Installation Source
Google Play Store
Additional Notes
App is actually 0.9.80-beta, no option for that.
Server version: v2.20.0 in docker.
The in-application logs do not catch this. I do have ADB debug logs though.
adb logs of crash
server logs
This happens for all audiobooks and not limited to a single one.
Let me know if there is anything else I can do to debug.
@nichwall commented on GitHub (Apr 24, 2025):
Are you downloading to Internal App Storage or shared storage?
Do you have enough space on your device? What kind of book are you downloading (single file, multiple files, how large, etc)
@Zibbp commented on GitHub (Apr 24, 2025):
I'm downloading to internal app storage. Device has plenty of free storage. Before the update on the 20th (v0.9.80-beta) this was working fine. All my audiobooks are single file
.m4b. The specific book in the logs is 571MB.@nichwall commented on GitHub (Apr 24, 2025):
Hm, I'm not able to replicate this on 0.9.80. This is probably related to https://github.com/advplyr/audiobookshelf-app/issues/1428. The crash log shows a divide by zero, which is used for calculating the percentage of the file which has been downloaded. Can you look at the book in the web interface and see if the server is reporting any of the files are reporting as 0 bytes?
@Zibbp commented on GitHub (Apr 24, 2025):
No 0 byte files -
I can download all 3 of those files through the web ui just fine.
I also tried reinstalling the Android client but that did not help.
@joutain commented on GitHub (Apr 24, 2025):
Similar issue for app crash on launching.
.80 version having issue and installed the .79 version back from the GitHub here resolved it. I have the Samsung s24+ with Android 15. Server side is the newest 2.20 on Synology container manager.
@nichwall commented on GitHub (Apr 24, 2025):
Is your app crashing or just showing a blank page? If so, you are likely experiencing https://github.com/advplyr/audiobookshelf-app/issues/1550
@joutain commented on GitHub (Apr 24, 2025):
My app is crashing.... Can't see the dashboard. Web browser access is fine
@Zibbp commented on GitHub (Apr 24, 2025):
Update with some more findings. I added my ABS server directly, no reverse proxy (Traefik), and it downloads fine.
I ran a packet capture and see the client start the download with a
/file/X/downloadroute and some data is sent to the client from the server then abruptly ends on the client side.So I took a look at my reverse proxy config, which is pretty simple. HTTPS redirect, some header stuff, and enabling gzip. I've seen some odd issues with gzip in the past so I figured I'd remove that for the ABS route. Sure enough, disabling gzip on the ABS route allows the download to complete!
So why does enabling gzip on the reverse proxy cause the audiobook file download to crash the app is the question now.
The HTTP request to download the file is sending an accept for gzip.
@nichwall commented on GitHub (Apr 24, 2025):
Oh, that's interesting, thanks for the extra detail. I think the total size of the download file is included in the header, so maybe the server does not provide the total size of the media file when downloading gzip, and that causes the issue on the app? Other endpoints (like normal API for request/response) support gzip, so the app is probably just using the same connection settings for all endpoints.
@joutain if your app is crashing when it opens and not crashing due to downloading a media file, please open a new issue
@nichwall commented on GitHub (Apr 24, 2025):
I have not been able to test this, but from initial research online, I believe this can be fixed by adding
.header("Accept-Encoding", "identity")to the okhttp client in the Android internal download Manager.This would be possible by changing https://github.com/advplyr/audiobookshelf-app/blob/e7ad62760f1398cff0acac42da63907034691abf/android/app/src/main/java/com/audiobookshelf/app/managers/InternalDownloadManager.kt#L21.
Change
to
to remove accepting gzip as an accepted encoding from the request.
@github-actions[bot] commented on GitHub (Apr 26, 2025):
Fixed in v0.9.81-beta.
@RobinXe commented on GitHub (May 23, 2025):
I am seeing this same issue still (crashes when trying to download any book) despite running v0.9.81-beta of the app, and server v2.23.0.
I am also running Traefik, and have worked around the problem for now by disabling gzip, but the fix may need revisiting.
@Maximepzv commented on GitHub (Jun 3, 2025):
I am facing the same issue, it still crash running v0.9.81-beta with server v2.21.0.
@RobinXe How did you disabled gzip ?
Only the mobile app seems to crash.
server logs
@RobinXe commented on GitHub (Jun 3, 2025):
I made a chain rule specifically for ABS and left out the compression middleware altogether.
@nichwall commented on GitHub (Jun 3, 2025):
Have you confirmed the headers the app is sending to download? I did not see anything else that needed to be changed to disable gzip from the app. If the app is requesting without gzip and the proxy is responding with gzip that sounds like a proxy misconfiguration.
@RobinXe commented on GitHub (Jun 3, 2025):
I have not I'm sorry, I didn't dig into it, I'll add it to my list of things to get to, but it's a long list! 😜
It could well be a proxy misconfiguration, but it was working with one version of the app, then wasn't after an update. Not sure which update sorry, as I was listening to a downloaded 19h book at about 45mins per weekday, and was about 90mins from the end when I tried to download the next and it failed.
@luismalves commented on GitHub (Jun 12, 2025):
Also having this issue with traefik. Was working before. Also had to disable compress in the middleware chain for this endpoint
@nichwall commented on GitHub (Jun 12, 2025):
Can you confirm the request header from the app?
@snipcodeit commented on GitHub (Jul 21, 2025):
I just experienced this and immediately started hunting for a fix.
I was able to create a second local folder from within the android interface (Pixel 9 Pro) and upon selecting the m4b to download to it, it worked! Purely speculation from me, I wonder if it's a permission thing?
I haven't examined this codebase, but I hope if anyone else comes across this they can solve it the same way until it's hopefully identified and patched in a future release.
@v3DJG6GL commented on GitHub (Jul 30, 2025):
I had the same issue.
After removing Cloudflare Tunnel for my audiobookshelf subdomain, downloading is working as excepted :)
Audiobookshelf mobile app seems to struggle with Cloudflare tunneling...
Since I have a public/static IP address, I don't really need Cloudflare Tunnel, but for reasons of anonymity, I still prefer it...
@aakashbashyal21 commented on GitHub (Oct 3, 2025):
I am also running my app through cloudfare tunnel and has a private IP. I am not able to download the files it get crashed, and also not able to skip forward any audios.
https://github.com/user-attachments/assets/3a252167-3cf6-4b3d-bd09-e5ed7e955fb1