starred/audiobookshelf
1
0
Fork 0
mirror of https://github.com/advplyr/audiobookshelf.git synced 2026-07-31 00:48:39 +02:00
Code Issues 1.0k Packages Projects Releases 10 Wiki Activity

[Bug]: Edge version: /items/{libraryItemID}/play causes API freeze and high memory usage after ~3 calls with large library items #3298

New Issue
Closed
opened 2026-04-25 00:14:48 +02:00 by adam · 8 comments
adam commented 2026-04-25 00:14:48 +02:00
Owner
Copy Link
Copy Source

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”

Image Image Image

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

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” <img width="1629" height="1048" alt="Image" src="https://github.com/user-attachments/assets/98876615-9e48-4ff8-bfe0-b86a90103ace" /> <img width="1104" height="647" alt="Image" src="https://github.com/user-attachments/assets/4e496a0d-9ede-44ca-bd26-766ba2ec3f0e" /> <img width="682" height="555" alt="Image" src="https://github.com/user-attachments/assets/a862268f-2d57-496c-8d15-d47e645cc6ee" /> ### 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 ```shell ``` ### Additional Notes _No response_
adam added the bug label 2026-04-25 00:14:49 +02:00
adam closed this issue 2026-04-25 00:14:49 +02:00
adam commented 2026-04-25 00:14:49 +02:00
Author
Owner
Copy Link
Copy Source

@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.

@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.
adam commented 2026-04-25 00:14:49 +02:00
Author
Owner
Copy Link
Copy Source

@yunxiuGona 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.

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.

Image Image
@yunxiuGona 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. 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. <img width="655" height="469" alt="Image" src="https://github.com/user-attachments/assets/478aa30e-d891-4770-90e2-620f6638f18f" /> <img width="1712" height="428" alt="Image" src="https://github.com/user-attachments/assets/8b0da55b-d5e6-4d52-843c-e7c958350509" />
adam commented 2026-04-25 00:14:49 +02:00
Author
Owner
Copy Link
Copy Source

@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.

@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.
adam commented 2026-04-25 00:14:49 +02:00
Author
Owner
Copy Link
Copy Source

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

Image

The version information is as follows.

Image
@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: <img width="409" height="267" alt="Image" src="https://github.com/user-attachments/assets/856787b1-9a6e-48e0-990a-ca70c04707c8" /> The version information is as follows. <img width="173" height="182" alt="Image" src="https://github.com/user-attachments/assets/32a653b2-2d35-4516-bb88-7eb622505d7c" />
adam commented 2026-04-25 00:14:49 +02:00
Author
Owner
Copy Link
Copy Source

@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.

@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.
adam commented 2026-04-25 00:14:49 +02:00
Author
Owner
Copy Link
Copy Source

@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.

@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.
adam commented 2026-04-25 00:14:49 +02:00
Author
Owner
Copy Link
Copy Source

@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

The MIME types that are supported by the client. If the MIME type of the audio file is not in this list, the server will transcode it

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

@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 > The MIME types that are supported by the client. If the MIME type of the audio file is not in this list, the server will transcode it 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
adam commented 2026-04-25 00:14:50 +02:00
Author
Owner
Copy Link
Copy Source

@yunxiuGona commented on GitHub (Apr 14, 2026):

Thanks

@yunxiuGona commented on GitHub (Apr 14, 2026): Thanks
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
authentication
backlog
bug
chapter editor
config-issue
ebooks
encoding/embedding
enhancement
help wanted
listening sessions & progress
planned
possible plugin
progress sync
pull-request
Mirrored from GitHub Pull Request
 sorting/filtering/searching
unable to reproduce
upload
users & permissions
waiting
No labels bug
Milestone
No items
No Milestone
Projects
Clear projects
No projects
Assignees
Clear assignees
adam (Adam Melkus)
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/audiobookshelf#3298