mirror of
https://github.com/advplyr/audiobookshelf.git
synced 2026-05-30 23:40:40 +02:00
[Bug]: "Match" has a slow race condition with user input #1476
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#1476
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 @wtanksleyjr on GitHub (Oct 21, 2023).
Describe the issue
After accepting metadata changes from a Match operation (from the dropdown on the book's library item), the edit-book modal dialog is offered to the user as though ready for editing. But if the user makes any changes before the system completely removes the green "Item details updated" banner, the user edits will be removed and reset to the book's state immediately following the Match.
Ideally, I'd like the modal dialogue to be ready for user input immediately after the dialogue appears. If that's not possible, it would be better to make the modal not editable until user input can be preserved.
Steps to reproduce the issue
Audiobookshelf version
2.4.4
How are you running audiobookshelf?
Docker
@advplyr commented on GitHub (Oct 21, 2023):
I'm not able to reproduce this. It also doesn't follow logically with the code because the duration of the toast is not related to anything else.
When you update a book, whether it is through the match tab or through the details tab, the server will emit a socket event notifying all clients of the update. If you have the edit modal open then the inputs will be updated when this socket event is received.
The only thing I can think of that is happening for you is that socket event is being delayed for you by either your client or your server. I can't think of how that would happen but you can do a simple test to see if my guess is correct.
The "Item updated" message is logged when the client receives the socket event I described above.
@wtanksleyjr commented on GitHub (Oct 22, 2023):
Interesting! So what I get is an instant "item updated", and then another "item updated" that comes in right as the green banner hides itself. How odd.
@advplyr commented on GitHub (Oct 22, 2023):
Can you run the same test except monitor the server logs at the same time? Perhaps that will show some other update happening a few seconds later.
@wtanksleyjr commented on GitHub (Oct 23, 2023):
Sure, let's see what I can do with docker logs. ...
On Sun, Oct 22, 2023 at 6:55 AM advplyr @.***> wrote:
@wtanksleyjr commented on GitHub (Oct 23, 2023):
Worked great (i.e. was able to recreate it). Here's all of the log entries. I notice one thng that I forgot to mention: I have an older setup (originally used ABS metadata) on which I enabled json metadata stored in the book-folders, and I observe it sees that and loads it a second time. That ... just MIGHT be the problem, maybe?
@advplyr commented on GitHub (Oct 24, 2023):
It has to do with the file watcher detecting the new cover added. Can you try testing this again but exclude the cover image when matching?
@wtanksleyjr commented on GitHub (Oct 24, 2023):
Sure, pending...
On Mon, Oct 23, 2023 at 3:03 PM advplyr @.***> wrote:
@wtanksleyjr commented on GitHub (Oct 24, 2023):
Yes, that seems to be likely; I couldn't make this happen so long as I
unchecked the cover. Nice!
On Mon, Oct 23, 2023 at 3:03 PM advplyr @.***> wrote:
@wtanksleyjr commented on GitHub (Oct 24, 2023):
Oops, I've done several more with the cover unchecked, and it did happen two more times. So it's less common, but not unheard-of, without the cover.
@advplyr commented on GitHub (Oct 28, 2023):
Can you reproduce this again showing the logs when you are not including the cover image?
From your previous logs it was pretty clear this was the watcher picking up the cover image and running a scan. The watcher has a few second delay which explains why it is lining up with the toast notification for you.
@wtanksleyjr commented on GitHub (Oct 29, 2023):
Here's a set of logs of the same thing without the cover image checked:
@advplyr commented on GitHub (Oct 29, 2023):
Something is creating or removing
metadata.absandmetadata.jsonfiles. Do you have some other scripts running? Do you have 2 instances of audiobookshelf running?@wtanksleyjr commented on GitHub (Oct 30, 2023):
None of my scripts touch anything in there except by moving a completely
populated folder in (I ran into problems otherwise). I only move folders
out manually, and never tinker otherwise.
Running 2 instances ... that would be quite a disaster. I'm only running
one that I know of, surely doing that would cause all kinds of problems
aside from this. I admit I don't know for absolutely sure, but ... it
doesn't seem very likely. Nor can I find any sign that I'm doing that.
-Wm
On Sun, Oct 29, 2023 at 5:02 AM advplyr @.***> wrote:
@advplyr commented on GitHub (Feb 28, 2024):
Are you still having this issue in 2.8.0?
@wtanksleyjr commented on GitHub (Feb 28, 2024):
I'll check. (I stopped using Match almost completely when I modified my Libation script to include the new expanded metadata - once I could put ALL of the Genre/Tags together into Tags, and then put only what I consider essential into the Genre, I found that I prefer it to the results of doing a Match.)
Be right back.
@wtanksleyjr commented on GitHub (Feb 28, 2024):
Yes, I still see the same thing reported.