Play, pause, seek and change replay speed

Control a saved server clock

Replay controls change how a frozen timeline is evaluated, not which source events belong to it. Play advances from the current position, Pause holds it, Seek chooses a position inside the frozen range and Speed changes the playback rate. The browser receives the current absolute analytics frame from the server; it does not own an independent authoritative clock that can bypass saved state.

Use controls in a predictable order

Read position and playback status after each operation, especially if another browser also has the replay open.

1. Create or reopen the intended replay and confirm its start/end.
2. Press Play and watch position advance.
3. Pause at an area of interest.
4. Seek to an explicit position within the frozen bounds.
5. Choose a supported speed from 0.1× through 16×, then click Apply speed. Changing the dropdown alone does not update the saved clock.
6. Read the resulting position/status before issuing another control.
7. Delete an unneeded replay using its own delete action.

End, restart and speed semantics

Changing speed preserves the current position and playing/paused state. Seeking to the end completes the replay. Playing a completed replay restarts it at its beginning. Saved controls use revisions to prevent concurrent browsers silently overwriting each other's clock changes. A failed candidate frame should not advance the stored position as though it had rendered successfully. Refresh state after a conflict instead of blindly repeating an outdated control.

Worked example: pause, seek backward, accelerate

Play a short retained replay, pause midway and record its position. Seek earlier, then select a faster speed while paused and click Apply speed. The replay should remain paused at the sought position; choosing a faster rate alone is not Play. Press Play to resume from there. If it reaches the end, its completed status is distinct from a lost connection. Reopen or reconnect to read the saved current frame rather than assuming the browser's last visible frame is authoritative.

Troubleshoot reconnects and service restarts

A playing clock can advance with elapsed server time across downtime; a paused clock retains position. New connections receive the current absolute frame, not a backlog of every skipped display frame. Expired/rotated credentials can require normal authentication refresh. If controls fail, capture replay ID, action, position, speed and status/error. Do not create a duplicate tape merely because a paused stream has no visibly changing data.

What the isolated timeline can establish

Retained replay uses a final-corrected canonical event timeline. Each retained identity's highest accepted revision is placed at its final event timestamp. This reconstructs corrected event time, not the exact information an exchange participant saw at every original arrival. Dated chain/reference seeds at or before the start can initialize the isolated engine. Later model inputs remain unavailable until their own source/model availability timestamp, and historical gamma frames stop at the current replay position.

Replay does not open a live provider feed, write live analytics or fire live alert callbacks. It cannot reconstruct a synchronized DOM or resting-liquidity book from an execution tape. A partial frozen tape is not expanded with today's full-session profile. Explicit synthetic fixture replay has a different mode and quality from retained replay. Read those labels and coverage together before interpreting a result. A saved replay selection demonstrates the requested analysis, while its actual eligible inputs determine which frames can be produced at each clock position.

Distinguish control state, frame sequence and connection state

The saved control revision protects mutations, while a visible frame sequence describes ordered clock/control publications. The analytics snapshot can also carry its own domain revision. These values are related evidence of state, not interchangeable counters. A browser can be connected to a paused replay without receiving changing market values. Conversely, a disconnected browser can miss display frames while the saved playing clock continues. Inspect playback status and position before diagnosing a frozen chart as a failed stream.

When two tabs control the same replay, one can make the other's revision stale. Reload current state and deliberately choose the next action; repeatedly pressing an old Seek request is not conflict resolution. Speed changes preserve the current point, and Play at the completed end restarts from the beginning. Seek does not move outside the frozen bounds or extend the tape. If a candidate frame fails, the server should preserve the prior accepted clock state rather than publishing success. Include action and before/after state in support reports so a clock problem can be separated from unavailable analytics at the requested position.