mirror of
https://github.com/advplyr/audiobookshelf.git
synced 2026-05-30 23:40:40 +02:00
[Bug]: Edge version: /items/{libraryItemID}/play causes API freeze and high memory usage after ~3 calls with large library items #3298
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#3298
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @yunxiuGona on GitHub (Apr 14, 2026).
What happened?
Environment:
OS: fnos
Deployment: Docker
Version: Audiobookshelf edge
Issue:
My library contains several books, each with around 3000 items. After calling /audiobookshelf/api/items/${libraryItemID}/play approximately 3 times, the entire audiobookshelf API becomes unresponsive and extremely slow, with very high memory consumption.
At this time, the Docker console log keeps repeatedly outputting a large number of lines:
“INFO: [STREAM-CHECK] Check Files 34493 of 146757 23.50% Furthest Segment”
What did you expect to happen?
No system lag occurs, and the API can be called normally.
Steps to reproduce the issue
My library contains several books, each with around 3000 items. After calling /audiobookshelf/api/items/${libraryItemID}/play
Audiobookshelf version
v2.26.0.
How are you running audiobookshelf?
Docker
What OS is your Audiobookshelf server hosted from?
Linux
If the issue is being seen in the UI, what browsers are you seeing the problem on?
None
Logs
Additional Notes
No response
@nichwall commented on GitHub (Apr 14, 2026):
The latest server version is
2.33.1. Please update to the latest server version and see if this issue is fixed.@yunxiuGona commented on GitHub (Apr 14, 2026):
I tried pinning the version of the Docker image:
docker pull advplyr/audiobookshelf:2.33.1
After running it, the issue still persists after several API calls.
I also tried:
docker pull advplyr/audiobookshelf:edge
The issue still exists.
@Vito0912 commented on GitHub (Apr 14, 2026):
What does the version say at the bottom left? Pulling alone will not update your container.
Apart from that, everything described here is not a bug, but just how transcoding works. You probably have a very weak server. Transcoding is a very demanding task, especially on weak servers.
Transcoding only happens if your device cannot play the file you uploaded. So if it's a standard format, the file is probably corrupted and you should either re-encode it or try to get the file again in a non-corrupted way. If it's an exotic codec, then it is expected to transcode. You can encode it first to a more supported format.
@yunxiuGona commented on GitHub (Apr 14, 2026):
Thank you very much for your reply. As I understand it, the audio files should have already been transcoded during the scanning process, right? Will the server keep transcoding during playback?
My current usage scenario is as follows:
Call the /audiobookshelf/api/items/${libraryItemID}/play API endpoint to retrieve media.audioFiles from the response.
Use an Android media player to directly play the http://xxx.mp3 file from audioFiles.
Then report the playback progress to the server every 3 minutes via the /audiobookshelf/api/session/$playItemID/sync endpoint.
The problem I’m facing now is: after calling the /audiobookshelf/api/items/${libraryItemID}/play endpoint a few times, the entire Audiobookshelf freezes. The corresponding web page at http://xxx::13378 becomes inaccessible, and the API can no longer be called. The issue does not recover even after a long wait, and I can only fix it by restarting the Docker container and accessing it again.
May I ask whether my usage scenario will trigger automatic transcoding on the server when the play endpoint is called?
Additionally, here is my personal NAS configuration information:
The version information is as follows.
@Vito0912 commented on GitHub (Apr 14, 2026):
That explains it probably. As said the weak performance comes from the weak cpu. This is expected. But why it completely goes unresponsive is unknown. Do you start multiple sessions so multiple cores are occupied?
You as an app developer are responsible to communicate the playable containers you device supports. E.g. check what the web client makes for an request. If you miss that and do not set force direct play, it will transcode.
Transcodes are not saved and also not generated on scanning. Transcodes are solely optional for devices that do not support a container/codec and are generated on the fly.
As for why the server goes completely unresponsive I am not sure. Transcoding will only use one core. You could check top while running e.g.
@yunxiuGona commented on GitHub (Apr 14, 2026):
Could you please help clarify these questions again?
1、If I start playback by calling /audiobookshelf/api/items/${libraryItemID}/play, do I need to manually call another API to end the playback process when exiting the player? Or will the server release resources automatically? Because on mobile apps, users may kill the process directly, which could leave the playback instance unreleased.
2、Will the parameters I pass when calling /audiobookshelf/api/items/${libraryItemID}/play (such as deviceId, model, sdkVersion) affect the server’s decoding method? Also, how should I configure it if I want decoding to be done on the app side instead of the server side?
Thank you very much.
@Vito0912 commented on GitHub (Apr 14, 2026):
Please consult the docs: https://api.audiobookshelf.org/#play-a-library-item-or-podcast-episode
It states everything and also states
These docs are out-of-date and I wouldn't normally recommend looking at them, as you can always check the web client what it does or check the repos code directly. In some cases the docs are wrong
@yunxiuGona commented on GitHub (Apr 14, 2026):
Thanks