Closed soapdog closed 3 years ago
I'm going to attempt to circumvent all things dealing with sTimestamp
for the journal. The handlers dealing with the journal will simply ask the values from the player and set them directly. Fiddling with sTimestamp
has proven too buggy the last few days.
This has been fixed. Unfortunately, this means that previous saved records in the journal won't work because they have the wrong data saved.
When resuming a journal entry, the audio ends up playing from the start instead of the recorded timestamp.
This is related to #274 and also to the fact that the desktop and mobile players use different measuring units while the stack keeps track of the running timestamp in milliseconds in a local variable called
sTimestamp
.I am coming to realise that all this hands-on tracking of the timestamp is a mistake. The only time when it is needed is when updating the timer, and when recording/resuming from the journal. All these features can request the running timestamp from the player object directly instead of relying on a local variable that is not being updated correctly.
The code related to that module is quite convoluted and there might be other aspects dealing with
sTimestamp
that I am not aware.