A podcast player can be loading, buffering, paused, seeking, or playing. The same visual spinner may appear in several of those states. Progress sync should follow the audio position, not the presence of a loading animation.
A common mistake is to start a wall-clock timer when the user presses Play. If the audio then buffers for twenty seconds, the saved position can move forward even though the listener heard nothing.
Read the media position
Use the media player's current playback position as the source for a progress checkpoint. Keep intended actions, such as a requested seek, separate until the player reports the resulting position.
Do not infer completion from a download reaching the end. Downloading a file and listening to it are different activities. An offline download can finish while the listener has not pressed Play at all.
If your platform emits position changes during a seek, decide when the application treats that position as stable enough to save. Apply the same rule to a remote control action and an on-screen scrubber.
Build a failure fixture
Serve a controlled media response slowly, interrupt it, then resume. While the player buffers, inspect the local pending state and network progress writes. They should match the actual media position.
Also test a play request that the browser rejects, a paused episode that remains open for an hour, and switching to another episode during loading.
A precise state model makes support reports easier to understand. “The player was open for ten minutes” should not automatically become “the person listened for ten minutes.” Preserve that distinction in your progress logic, analytics labels, and product copy.