starred/audiobookshelf
1
0
Fork 0
mirror of https://github.com/advplyr/audiobookshelf.git synced 2026-05-30 23:40:40 +02:00
Code Issues 1.0k Packages Projects Releases 10 Wiki Activity

[Bug]: "Add to collection" is slow/crashes, especially on mobile devices #2339

New Issue
Open
opened 2026-04-25 00:06:16 +02:00 by adam · 6 comments
adam commented 2026-04-25 00:06:16 +02:00
Owner
Copy Link
Copy Source

Originally created by @xcy7e on GitHub (Oct 30, 2024).

What happened?

I have ~20 collections with ~200 titles related in total.
Depending on the device (Laptop is fine, mobile device is unusable) it takes minutes until the list of collections loaded, when trying to add a title to a collection.

Advplyr once told me, this is because of the old objectional DB schema.

I wonder if it can be improved, either by migrating the affected table schemas or by Changing the "load collections" function.
There was a patch, that brought improvement, quite a while ago, but not significantly.

I assume it wouldn't be necessary to load all related titles when loading the collections in this specific context, but rather only the first 2 for the covers and the current context's title to see where it has been added already.

Personally I would't even need the Covers in that modal List.

Another workaround could be, to be able to add titles from within a collection.

On my Galaxy S20 I am at the point where I can't add more titles, since the browser crashes everytime. It seems, it's loading way too many things.

This makes the "Collections" - Feature mostly unusable to me & most of my users.

What did you expect to happen?

Collections List modal loads within seconds

Steps to reproduce the issue

  1. Add 10-20 collections
  2. Relate 100-200 titles to the collections in total
  3. Try to add a title to a collection on a mobile device
  4. Takes minutes to load or crashes due to memory exhaustion

Audiobookshelf version

v2.16.2

How are you running audiobookshelf?

Debian/PPA

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?

Other (list in "Additional Notes" box)

Logs

INFO

[SocketAuthority] Socket TxIQgNFGpDSPrAiRAAAT disconnected from client "jonathan" after 196972ms (Reason: transport close)

Additional Notes

Affects every mobile browser similary

Originally created by @xcy7e on GitHub (Oct 30, 2024). ### What happened? I have ~20 collections with ~200 titles related in total. Depending on the device (Laptop is fine, mobile device is unusable) it takes **minutes** until the list of collections loaded, when trying to **add a title to a collection**. _Advplyr_ once told me, this is because of the old objectional DB schema. I wonder if it can be improved, either by migrating the affected table schemas or by Changing the "load collections" function. There was a patch, that brought improvement, quite a while ago, but not significantly. I assume it wouldn't be necessary to load all related titles when loading the collections in this specific context, but rather only the first 2 for the covers and the current context's title to see where it has been added already. Personally I would't even need the Covers in that modal List. Another _workaround_ could be, to be able to _add titles from within a collection_. On my Galaxy S20 I am at the point where **I can't add more titles**, since the browser **crashes everytime**. It seems, it's loading way too many things. This makes the "Collections" - Feature mostly unusable to me & most of my users. ### What did you expect to happen? Collections List modal loads within seconds ### Steps to reproduce the issue 1. Add 10-20 collections 2. Relate 100-200 titles to the collections in total 3. Try to add a title to a collection on a mobile device 4. Takes minutes to load or crashes due to memory exhaustion ### Audiobookshelf version v2.16.2 ### How are you running audiobookshelf? Debian/PPA ### 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? Other (list in "Additional Notes" box) ### Logs ```shell INFO [SocketAuthority] Socket TxIQgNFGpDSPrAiRAAAT disconnected from client "jonathan" after 196972ms (Reason: transport close) ``` ### Additional Notes Affects every mobile browser similary
adam added the bug label 2026-04-25 00:06:16 +02:00
adam commented 2026-04-25 00:06:16 +02:00
Author
Owner
Copy Link
Copy Source

@nichwall commented on GitHub (Oct 30, 2024):

Would you be willing to share your database so I can do some testing with the large collections? You can zip it to make it much smaller, then send it to the email on my GH profile or to nyxholas on the ABS Discord.

@nichwall commented on GitHub (Oct 30, 2024): Would you be willing to share your database so I can do some testing with the large collections? You can zip it to make it much smaller, then send it to the email on my GH profile or to nyxholas on the ABS Discord.
adam commented 2026-04-25 00:06:16 +02:00
Author
Owner
Copy Link
Copy Source

@xcy7e commented on GitHub (Nov 17, 2024):

@nichwall I prepared the database & sent you an email with further details for the data exchange.

@xcy7e commented on GitHub (Nov 17, 2024): @nichwall I prepared the database & sent you an email with further details for the data exchange.
adam commented 2026-04-25 00:06:17 +02:00
Author
Owner
Copy Link
Copy Source

@advplyr commented on GitHub (May 10, 2025):

Is this still an issue or did we find out any more info? I haven't reproduced this

@advplyr commented on GitHub (May 10, 2025): Is this still an issue or did we find out any more info? I haven't reproduced this
adam commented 2026-04-25 00:06:17 +02:00
Author
Owner
Copy Link
Copy Source

@xcy7e commented on GitHub (May 10, 2025):

@nichwall did not respond to me.

To my suspicion there is still too much processing when adding a book to a collection (the "collections listing in the modal"-Part), because it has exponetially increased in time by the size of the collections.

Details for reproduction

  1. Client devices with better CPUs than my smartphone don't have this problem (or at least it's loading for a while, but working finally)
  2. ~20 collections with 300 books related in total
  3. It very much depends on the servers ressources!

Problematic server ressources

vServer / debian with

  • (HDD for media files // SSD for metadata + db)
  • 2x vCPUs (AMD x64)
  • 2GB RAM

Server resource treshold

Scaling up to...

  • x3 vCPUs
  • 4GB RAM

...the requests do not die anymore & the collections-modal loaded after 20 seconds on my higher mid-class smartphone.
Scaling up further reduces the time drastically.

I did not look into the code, but suspect it might use an inefficient/overloaded query..?
You might close this, as using the Feature on mobile Browsers could be neglected, I think.

@xcy7e commented on GitHub (May 10, 2025): @nichwall did not respond to me. To my suspicion there is still too much processing when adding a book to a collection (the "_collections listing in the modal_"-Part), because it has exponetially increased in time by the size of the collections. --- ## Details for reproduction 1. **Client devices** with better CPUs than my smartphone don't have this problem (or at least it's loading for a while, but working finally) 2. ~20 collections with 300 books related in total 3. It very much depends on the servers ressources! ### Problematic server ressources vServer / debian with - (`HDD for media files` // `SSD for metadata + db`) - `2x vCPUs` (AMD x64) - `2GB RAM` ### Server resource treshold Scaling up to... - `x3 vCPUs` - `4GB RAM` ...the requests do **not** die anymore & **the collections-modal loaded** after 20 seconds on my higher mid-class smartphone. Scaling up further reduces the time drastically. --- I did not look into the code, but suspect it might use an inefficient/overloaded query..? You might close this, as using the Feature on mobile Browsers could be neglected, I think.
adam commented 2026-04-25 00:06:17 +02:00
Author
Owner
Copy Link
Copy Source

@nichwall commented on GitHub (May 10, 2025):

Oh, shoot. Sorry, I completely forgot about this one.

@nichwall commented on GitHub (May 10, 2025): Oh, shoot. Sorry, I completely forgot about this one.
adam commented 2026-04-25 00:06:17 +02:00
Author
Owner
Copy Link
Copy Source

@advplyr commented on GitHub (May 10, 2025):

Thanks, I think we should keep it open because it shouldn't be an issue on mobile. The API can be optimized more

@advplyr commented on GitHub (May 10, 2025): Thanks, I think we should keep it open because it shouldn't be an issue on mobile. The API can be optimized more
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 Label bug
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
adam (Adam Melkus)
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/audiobookshelf#2339
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?