mirror of
https://github.com/advplyr/audiobookshelf.git
synced 2026-05-30 23:40:40 +02:00
[Bug]: Saved Media Progress showing double entries #2494
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#2494
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 @matieke on GitHub (Jan 16, 2025).
What happened?
When going through a user's Saved Media Progress there are double entries.
Users showing this issue are using Plappa 1.5.0
What did you expect to happen?
Saved Media Progress should only show 1 entry for each book.
Steps to reproduce the issue
Audiobookshelf version
2.17.7
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?
Chrome
Logs
No response
Additional Notes
@advplyr commented on GitHub (Jan 17, 2025):
Can you check the created timestamps for those to see if they are the same time? That would indicate a race condition
@matieke commented on GitHub (Jan 30, 2025):
I checked a couple where progress was at 0% but still had a duplicate entry.
"The eyes are the best part" audiobook for example has only 1 listening session logged of 36s.
Now even triple entries are being created also with only 1 listening session.
All occurrences of this bug present as 1 entry having the correct progress percentage while the duplicates stay at 0%
@advplyr commented on GitHub (Jan 30, 2025):
Can you check the created timestamps for those to see if they are the same time? That would indicate a race condition
@matieke commented on GitHub (Jan 30, 2025):
I'm not entirely sure what you mean, taking "The eyes are the best part" as an example. The user only has 1 timestamp in the listening history.
There are no duplicate timestamps, only duplicate entries in the saved media progress
@advplyr commented on GitHub (Jan 30, 2025):
@matieke commented on GitHub (Jan 30, 2025):
Yes, they all have the exact same timestamp.
@akriegshauser commented on GitHub (Feb 25, 2025):
My related issue #4038 does not duplicate media progress until the book is complete.
@argash commented on GitHub (Feb 26, 2025):
Just want to note that I am also seeing this behavior. I'm currently on 2.19.5 and the current version of Plappa. I will note it doesn't seem to happen every time though. Happy to help provide logs or anything else you might want me to test.
@akriegshauser commented on GitHub (Feb 27, 2025):
I have some more insight into this - I listen on both Plappa and through ABS on Chrome.
Today I started another book with my first listening session of it being on Plappa, and when I went to pick it up on ABS, I noticed a duplicate entry appear (this contradicts what I was previously reporting). I have since finished the book and it is now stuck in "Continue Listening" as well, showing a progress entry at 0% and one at 100%.
To test this theory, I have since started another book with my first listening session being on ABS via Chrome, and I currently do not see any duplicated events.
Below are all the logs generated relating to this book. Not sure if relevant as the logs may be related to playback, but I did not request Plappa download the book files to my device. These coincide with when I was listening to the book via Plappa, and no entries show for my ABS listening in the afternoon.
@nichwall commented on GitHub (Feb 27, 2025):
The aborted downloads seems to be related to Plappa, as reported in https://github.com/advplyr/audiobookshelf/issues/3803
@Vito0912 commented on GitHub (Apr 12, 2025):
I came across this issue, because of Discord.
I don't know if it is related (and I did not check every related issue, so sorry if this has been brought up), but after I checked https://github.com/advplyr/audiobookshelf/issues/4196, I noticed Plappa uses an unconventional method for syncing progress:
https://github.com/advplyr/audiobookshelf/issues/4196#issuecomment-2797497694
Specifically, instead of syncing
/sync, the following endpoints are used:/api/session/local/api/me/progress/batch/update/api/authorizeThe first two endpoints is used to sync the session. I can imagine there is a race condition that creates double entries since both requests are executed at the same time.
Additionally, the third endpoint is also executed every sync (approximately every 10 seconds), loading all media data each time. This might also create a race condition (bc loading while updating (?)). I am actually surprised that nobody has complained about data usage for Plappa, as the user endpoint gets quite large very quickly (at least I found no issue).
However, I can imagine that all of this creates some race condition or similar issue. The developer said he will refine the API endpoints eventually (no ETA) but still we should investigate further.
@Vito0912 commented on GitHub (Jun 19, 2025):
I found the cause.
It is indeed a race condition that happens when
/api/session/localand/api/me/progress/batch/updateare used at the same time, because both create a new progress.I cannot say if or when this will be fixed on the ABS site. Unfortunately, I do not know enough about the backend (regarding the model schema / SQL lite) right now to fix this myself.
But at least I can tell how to avoid it :): To avoid this problem for now, start the book using another app or the web, wait for the first sync (for the official apps, this should take about 20 seconds), and then listen with Plappa. The issue should only occur if there is no progress and you start the first progress with plappa
Tagging @LeoKlaus so you are informed.