Bug 466795 - Playback jumps back when manually syncing while episode is playing
Summary: Playback jumps back when manually syncing while episode is playing
Status: RESOLVED FIXED
Alias: None
Product: kasts
Classification: Applications
Component: general (show other bugs)
Version: unspecified
Platform: Microsoft Windows Microsoft Windows
: NOR normal
Target Milestone: ---
Assignee: bart
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2023-03-03 21:38 UTC by benmordecai
Modified: 2024-04-24 07:47 UTC (History)
0 users

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments
Clocks between server and client within 1s (51.34 KB, image/png)
2023-03-10 16:26 UTC, benmordecai
Details

Note You need to log in before you can comment on or make changes to this bug.
Description benmordecai 2023-03-03 21:38:54 UTC
KASTS VERSION 23.,03.70

STEPS TO REPRODUCE
1. Set up Nextcloud gpoddersync backend 
2. Play an episode
3. Manually trigger sync

OBSERVED RESULT
Playback jumps back a few seconds, likely drawing from the server the saved position that was pushed to the server when sync was initiated.

EXPECTED RESULT
Playback continue as normal



SOFTWARE/OS VERSIONS
Windows: 11
 
KDE Frameworks Version: 5.103.0
Qt Version: 5.15.8

ADDITIONAL INFORMATION
Currently subscribed to 20 podcasts. 
Using Nextcloud gpoddersync 
Example was with a downloaded, not streamed episode.
No errors in error log. 
VLC Player Backend
Comment 1 bart 2023-03-10 15:14:27 UTC
Looking at the code I wouldn't expect this to happen since the remote episode actions are retrieved from the server before the local ones are uploaded.  (This is needed anyway because we first need to solve any conflicts before sending the new action updates to the server.)
Only the retrieved remote actions that are not superseded by a newer local one are then applied locally.

So I would expect that a jump can only happen by picking up remote actions that have been uploaded on a previous sync, not the current one.

The only way I can think of this happening would be if the clocks of the server and the client are not synced, or one or both have an incorrect timezone set.  All internal timestamps are relative to UTC, but the conversion might be wrong if Kasts gets a wrong local timezone.  If any of those conditions would happen, then Kasts might get confused and might apply actions in the correct order/precedence.
Comment 2 benmordecai 2023-03-10 16:26:20 UTC
Created attachment 157175 [details]
Clocks between server and client within 1s

The clocks of the server and the client are within one second of each other and synced with systemd-timesyncd
Comment 3 bart 2024-04-18 13:37:50 UTC
Using Kasts almost daily, I noticed one occurence of this bug since this bug report was opened.
I wasn't able to figure out exactly which chain of events led to this one occurence.

Do you still encounter it (regularly)?
Comment 4 benmordecai 2024-04-18 13:41:13 UTC
I have not used Kasts enough recently to know one way or the other, in large part because I have AntennaPod for my phone and Kasts for my computers, but I manage my listening through the queue. Since the AntennaPod queue is separate from the Kasts queue, I would have to manually manage both queues and so I typically just connect my phone to my computer audio with bluetooth and play from there.
Comment 5 benmordecai 2024-04-18 13:51:08 UTC
Just successfully synced with no reproduction of the bug. Previously it was every time.
Comment 6 bart 2024-04-24 07:47:06 UTC
Thanks for checking again.
I'll close this for now. Feel free to reopen at any time if it starts reoccuring.
(I'm trying to clean up the bug reports such that it's easier to focus on the really important ones. ;-))