Open darthrater78 opened 1 year ago
Please share mobile android version
964 beta
I have this issue in 9.65-beta too. I've actually seen it ignore the locally held position and override it with a position hours old (and hours behind position) from the server.
A check for the position write timestamp during position sync is probably required.
I've had a similar issue a few times but not able to narrow the down steps. However, this morning I was listening to a book on a bluetooth headset. Got in vehicle to leave and it transferred audio to the vehicle. I disconnected the vehicle bluetooth to continue listening with the headset. When I hit play again on the headset, the book had jumped from 53 minutes back to 4 minutes. I am able to use the history to jump back.
As the bluetooth changes happened I was driving away from my house so wifi was lost and the server is not open external so it lost connection (book was local). While I don't think that is the issue I want to mention it.
Screenshot of the history:
Describe the issue
When streaming a podcast and losing connectivity from wifi, the file continued to play until it reached the end of the buffer. This was fine.
However, when connectivity was re-established the file restarted from the point of lost connectivity instead of keeping the mobile client as the "source of truth" for progress and updating the server. This has also happened with audiobooks that are downloaded.
The mobile client should be the arbiter of most recent progress, or have an option that enables that.
Steps to reproduce the issue
Audiobookshelf version
v2.2.23
How are you running audiobookshelf?
Other