mirror of
https://github.com/advplyr/audiobookshelf.git
synced 2026-05-30 23:40:40 +02:00
[Bug]: UI frozen after going from the details of book 4 to book 3 in a specific series #2977
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#2977
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 @Phantomwise on GitHub (Aug 30, 2025).
What happened?
Hi, here's a weird one:
What did you expect to happen?
Being able to go from book 4 to book 3.
Steps to reproduce the issue
¯_(ツ)_/¯
Audiobookshelf version
v2.29.0
How are you running audiobookshelf?
Docker
What OS is your Audiobookshelf server hosted from?
Other (list in "Additional Notes" box)
If the issue is being seen in the UI, what browsers are you seeing the problem on?
Firefox
Logs
Additional Notes
Server running in a docker container on DSM.
No weird filenames with unusual characters:
No super deep nesting, they're in my library root folder for now.
2025-08-30.txt
@nichwall commented on GitHub (Aug 30, 2025):
Can you add the logs from your browser from pressing F12? It sounds like something in the frontend is having issues.
@Phantomwise commented on GitHub (Aug 30, 2025):
After a few more tries:
@Phantomwise commented on GitHub (Aug 30, 2025):
Thanks for the suggestion! I reloaded and caused the problem again:
The problem doesn't actually happen every time with the console open, I had to go back and forth twice between the books to cause it again
Does that mean the problem is on my side?
Edit: Fixed the broken code block
@nichwall commented on GitHub (Aug 30, 2025):
Awesome, thanks. It's likely there is something weird in your database that is causing the front end to have an error.
I still want to figure out what is actually happening so it can be fixed, so if you're willing to help with that debugging some more, please make a backup of your database (in the server settings) so we can do some comparisons between the database if the issue is resolved by the next steps. If you are comfortable sending the database to me and don't want to hunt down the exact issue, I can do this debugging on my server (can use the e-mail on my GitHub profile or a DM on Discord). If you want to remove all user information from that database, you can use the following commands while your Audiobookshelf server is not running:
Can you look at the request and response in the network tab as well? Once you have made the backup, you can also try editing the metadata fields on book 3 to see if you can determine if a specific metadata field is causing the issue, then compare to the previous value.
@Phantomwise commented on GitHub (Aug 30, 2025):
Thanks for the help! I have absolutely no idea what I'm doing but sure I'm willing to try 😁
I did made a backup but I don't think my email provider or discord would be happy with sending 300MB files...
The TypeError happens when I go from book 5 to 4, and then the freeze happens when going from 4 to 3
@nichwall commented on GitHub (Aug 30, 2025):
Ha yeah they generally aren't. If you have a file sharing site like Google Drive that works too, I can download it and then you can delete it and just email/DM a link.
Does it also happen when going from book 2 to 3? You mentioned that 4>5>4>3 would freeze on book 3, but do you get the type error for both instances of book 4?
@Phantomwise commented on GitHub (Aug 30, 2025):
I created a free trial account for MEGA but it'll take a while to upload.
In the meantime I tried to open the database without much luck, so I guess I'll be poking around until it's done.
@nichwall commented on GitHub (Aug 30, 2025):
Thanks for helping to debug this. I was able to reproduce the web client locking up using the database backup you sent me. The issue is due to you having the same tag existing twice on the same book (in this case, book 4). If you remove one of the
Policiertags from that book, you should be able to reload the page and use the web client normally again.@Phantomwise commented on GitHub (Aug 30, 2025):
Thanks a lot!
I can confirm the problem doesn't reoccur after removing the double tags, I don't see any TypeError anymore and the UI doesn't freeze.
It's a bit weird that the TypeError only happened for that book, when all of the series had the same tag twice, but as long as it works.
I think I know how it happened:
It might be worth fixing so that Audiobookshelf never writes the same tag twice when matching if that risks causing problems. Or doesn't try to break up the tags with commas.
Anyway thanks again!
@Vito0912 commented on GitHub (Aug 30, 2025):
ABS itself should not split anything. It is a requested feature for that to say.
Maybe the metadata.json had some problems and this the tag was added twice, or maybe the files embedded metadata.
If you can reproduce this (not being the embedded metadata of the file. This would be more a file error then) it would be nice to have some steps to reproduce it
@Phantomwise commented on GitHub (Aug 30, 2025):
The double tag is easy to replicate, it happen when you match any book with Audible.fr to ASIN B0BVT78R3D (Harry Fox book 4) or others in the same series.
On Audible.fr, the book 4 of the Harry Fox series shows the following categories:
From what I've seen, it's those categories that are used as tags when fetching metadata in audiobookshelf.
But during matching, audiobookshelf shows this for the tags:
Currently: Whatever(embedded metadata, doesn't matter at all)Policier+Policier et crimes internationaux+Action et aventure+Policier+thrillers et œuvres à suspenseI've noticed that all Audible.fr categories that contain a comma get split into several tags, it's not just this book. And apparently it means that if it would give you twice the same tag then you get the same tag twice...
@Vito0912 commented on GitHub (Aug 30, 2025):
Actually this is an Audible issue, issuing the tag twice. Thanks for reporting. I will fix this in a tomorrow PR!
@nichwall commented on GitHub (Aug 30, 2025):
Oh yeah, that's a really good find. A lot of the time when this type of bug happens people don't know when the issue came up (which is fair, especially if you don't notice for several weeks or something), so glad we know the cause.
If you're taking a look at this @Vito0912 , might be worth just adding the duplicate check when we go to update the database instead of at the provider level so it applies to all providers and scanning.
@github-actions[bot] commented on GitHub (Dec 21, 2025):
Fixed in v2.32.0.