[Bug]: OOM_Kill in Background #1269

Open
opened 2026-04-24 23:56:10 +02:00 by adam · 9 comments
Owner

Originally created by @realredknight on GitHub (Aug 23, 2025).

I have verified that the bug is not already awaiting release

Yes

What was the Problem?

When playing a book with multiple files and turning the app into background, it gets oom_killed with the system reporting 2 to 3 GiB free RAM afterwards.

Book Files themselves are about 200 MiB of Size (OPUS codec)

Steps to Reproduce the Issue

  1. Download a book with multiple files
  2. Press play
  3. change the active app
  4. wait

What was Expected?

Playing Audio should not consume that much RAM. The App should play on and free the RAM of played files

Phone Model

Samsung Galaxy Tab S7 (SM-T875, 6 GiB RAM)

Phone OS

Android 13

Audiobookshelf App Version

Android App - 0.10.0

Installation Source

Google Play Store

Additional Notes

Also reproducible on Fairphone 4 (android 13, 8 GiB RAM)

As recommended on Discord I checked adb logcat and attached one with *:W and one filtering for "audiobookshelf"

adb_audiobookshelf.txt
adb_w.txt

Originally created by @realredknight on GitHub (Aug 23, 2025). ### I have verified that the [bug is not already awaiting release](https://github.com/advplyr/audiobookshelf-app/issues?q=is%3Aissue%20label%3A%22awaiting%20release%22) Yes ### What was the Problem? When playing a book with multiple files and turning the app into background, it gets oom_killed with the system reporting 2 to 3 GiB free RAM afterwards. Book Files themselves are about 200 MiB of Size (OPUS codec) ### Steps to Reproduce the Issue 1. Download a book with multiple files 2. Press play 3. change the active app 4. wait ### What was Expected? Playing Audio should not consume that much RAM. The App should play on and free the RAM of played files ### Phone Model Samsung Galaxy Tab S7 (SM-T875, 6 GiB RAM) ### Phone OS Android 13 ### Audiobookshelf App Version Android App - 0.10.0 ### Installation Source Google Play Store ### Additional Notes Also reproducible on Fairphone 4 (android 13, 8 GiB RAM) As recommended on Discord I checked adb logcat and attached one with *:W and one filtering for "audiobookshelf" [adb_audiobookshelf.txt](https://github.com/user-attachments/files/21950356/adb_audiobookshelf.txt) [adb_w.txt](https://github.com/user-attachments/files/21950357/adb_w.txt)
adam added the bugandroid labels 2026-04-24 23:56:10 +02:00
Author
Owner

@Salvoxia commented on GitHub (Aug 27, 2025):

Confirming that exact behavior, I see the same log entries with Audiobookshelf on a Samsung Galaxy S20 (Android 13).
This behavior started with app version 0.10.0.
I experience it with an audio book with 157 tracks (mp3). Another audio book with 65 tracks (mp3) does not cause any crashes.

Happy to provide log files as well when given directions.

@Salvoxia commented on GitHub (Aug 27, 2025): Confirming that exact behavior, I see the same log entries with Audiobookshelf on a Samsung Galaxy S20 (Android 13). This behavior started with app version 0.10.0. I experience it with an audio book with 157 tracks (mp3). Another audio book with 65 tracks (mp3) does not cause any crashes. Happy to provide log files as well when given directions.
Author
Owner

@Vito0912 commented on GitHub (Aug 30, 2025):

@Salvoxia does this happen after a given time, after a track switch or anything else noticeable or just randomly?

Can you please provide the logs too?

@Vito0912 commented on GitHub (Aug 30, 2025): @Salvoxia does this happen after a given time, after a track switch or anything else noticeable or just randomly? Can you please provide the logs too?
Author
Owner

@Salvoxia commented on GitHub (Aug 30, 2025):

Unfortunately this happens completely at random. It might happen a couple of seconds after I resumed playing, might run for 15minutes before crashing all of a sudden. Not related to track changes.

This is the output of adb logcat | findstr "audiobookshelf" (Windows host) from a recent crash:
adb_logcat.log

Please let me know if I can help with anything else.

@Salvoxia commented on GitHub (Aug 30, 2025): Unfortunately this happens completely at random. It might happen a couple of seconds after I resumed playing, might run for 15minutes before crashing all of a sudden. Not related to track changes. This is the output of `adb logcat | findstr "audiobookshelf"` (Windows host) from a recent crash: [adb_logcat.log](https://github.com/user-attachments/files/22058625/adb_logcat.log) Please let me know if I can help with anything else.
Author
Owner

@Vito0912 commented on GitHub (Aug 30, 2025):

I am not sure if that is the cause, but please increase your body size. You have to many local session that it runs into your RP limitations:

08-30 15:44:00.960 776 2420 E AbsLogger: sendSyncLocalSessions: Failed to sync local sessions. (Unexpected code Response{protocol=h2, code=413, message=, url=https://audiobookshelf.example.com/api/session/local-all})

@Vito0912 commented on GitHub (Aug 30, 2025): I am not sure if that is the cause, but please increase your body size. You have to many local session that it runs into your RP limitations: `08-30 15:44:00.960 776 2420 E AbsLogger: sendSyncLocalSessions: Failed to sync local sessions. (Unexpected code Response{protocol=h2, code=413, message=, url=https://audiobookshelf.example.com/api/session/local-all})`
Author
Owner

@Salvoxia commented on GitHub (Aug 30, 2025):

Nice catch. I'm running ABS in a docker container behind Traefik. I spent the last 2 hours trying to find out if traefik has a maximum request body size, and all I've found and tried suggests that's not the case - the default is not setting a limit here.
However, I don't see the status code 413 in ABS' own server logs, even with debug log level.
Any ideas?

In the meantime I'll keep listing in offline mode and see if it crashes there - I guess if it does, that proves that this error is not related?

Edit: Ok, Managed to get ABS server itself to throw the error

PayloadTooLargeError: request entity too large
    at readStream (/app/node_modules/raw-body/index.js:156:17)
    at getRawBody (/app/node_modules/raw-body/index.js:109:12)
    at read (/app/node_modules/body-parser/lib/read.js:79:3)
    at jsonParser (/app/node_modules/body-parser/lib/types/json.js:135:5)
    at Layer.handle [as handle_request] (/app/node_modules/express/lib/router/layer.js:95:5)
    at trim_prefix (/app/node_modules/express/lib/router/index.js:328:13)
    at /app/node_modules/express/lib/router/index.js:286:9
    at Function.process_params (/app/node_modules/express/lib/router/index.js:346:12)
    at next (/app/node_modules/express/lib/router/index.js:280:10)
    at urlencodedParser (/app/node_modules/body-parser/lib/types/urlencoded.js:100:7)

Since it's running in Docker, I'm not sure there's something I can do about that. I guess that might be the topic for a separate issue.

@Salvoxia commented on GitHub (Aug 30, 2025): Nice catch. I'm running ABS in a docker container behind Traefik. I spent the last 2 hours trying to find out if traefik has a maximum request body size, and all I've found and tried suggests that's not the case - the default is not setting a limit here. However, I don't see the status code 413 in ABS' own server logs, even with debug log level. Any ideas? In the meantime I'll keep listing in offline mode and see if it crashes there - I guess if it does, that proves that this error is not related? Edit: Ok, Managed to get ABS server itself to throw the error ``` PayloadTooLargeError: request entity too large at readStream (/app/node_modules/raw-body/index.js:156:17) at getRawBody (/app/node_modules/raw-body/index.js:109:12) at read (/app/node_modules/body-parser/lib/read.js:79:3) at jsonParser (/app/node_modules/body-parser/lib/types/json.js:135:5) at Layer.handle [as handle_request] (/app/node_modules/express/lib/router/layer.js:95:5) at trim_prefix (/app/node_modules/express/lib/router/index.js:328:13) at /app/node_modules/express/lib/router/index.js:286:9 at Function.process_params (/app/node_modules/express/lib/router/index.js:346:12) at next (/app/node_modules/express/lib/router/index.js:280:10) at urlencodedParser (/app/node_modules/body-parser/lib/types/urlencoded.js:100:7) ``` Since it's running in Docker, I'm not sure there's something I can do about that. I guess that might be the topic for a separate issue.
Author
Owner

@Vito0912 commented on GitHub (Aug 30, 2025):

I am a bit confused tbh.
I didn't even know ABS can throw 413.

I used this exact endpoint in one of my scripts to upload 2 years of very active listening sessions (like 5k sessions) in one requests with no issue.

So either it is your proxy that limits it or there is something seriously wrong with your payload.

If it's not the proxy the only thing I could ask you is to clean your app storage for the app. This will resolve this, but you need to redownload the downloads and lose all non synced progress

@Vito0912 commented on GitHub (Aug 30, 2025): I am a bit confused tbh. I didn't even know ABS can throw 413. I used this exact endpoint in one of my scripts to upload 2 years of very active listening sessions (like 5k sessions) in one requests with no issue. So either it is your proxy that limits it or there is something seriously wrong with your payload. If it's not the proxy the only thing I could ask you is to clean your app storage for the app. This will resolve this, but you need to redownload the downloads and lose all non synced progress
Author
Owner

@Salvoxia commented on GitHub (Aug 30, 2025):

Looking at this issue adds to my confusion. It makes it look like the Payload too large error can occur in ABS' own logs even if caused by the reverse proxy.
I don't quite understand how that's possible or how that could work, but this invalidates my assumption that the error must be caused by ABS itself.

I tested manually uploading an 800MB file from ABS admin interface, and that worked.
I'm puzzled, going to clean my app storage , do a fresh installation and check if that affects the crashing this issue is about. Syncing progress works fine, so all I'm going to lose is listening history for who knows how long. Could be worse.

@Salvoxia commented on GitHub (Aug 30, 2025): Looking at [this issue](https://github.com/advplyr/audiobookshelf/issues/4138) adds to my confusion. It makes it look like the `Payload too large` error can occur in ABS' own logs even if caused by the reverse proxy. I don't quite understand how that's possible or how that could work, but this invalidates my assumption that the error must be caused by ABS itself. I tested manually uploading an 800MB file from ABS admin interface, and that worked. I'm puzzled, going to clean my app storage , do a fresh installation and check if that affects the crashing this issue is about. Syncing progress works fine, so all I'm going to lose is listening history for who knows how long. Could be worse.
Author
Owner

@Salvoxia commented on GitHub (Aug 31, 2025):

New installation, cleared app storage, re-downloaded my audio book, got another crash while not connected to the server.
adb_logcat_abs.log

@Salvoxia commented on GitHub (Aug 31, 2025): New installation, cleared app storage, re-downloaded my audio book, got another crash while not connected to the server. [adb_logcat_abs.log](https://github.com/user-attachments/files/22067716/adb_logcat_abs.log)
Author
Owner

@Salvoxia commented on GitHub (Sep 12, 2025):

Trying to raise visibility, I can confirm this issue persists with version v0.10.1-beta.
Had to temporarily switch to another third-party ABS client to keep my sanity :(

@Salvoxia commented on GitHub (Sep 12, 2025): Trying to raise visibility, I can confirm this issue persists with version [v0.10.1-beta](https://github.com/advplyr/audiobookshelf-app/releases/tag/v0.10.1-beta). Had to temporarily switch to another third-party ABS client to keep my sanity :(
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/audiobookshelf-app#1269