fix: replay mode loops by default instead of stopping at end

[spomichter]

Problem

Replay mode plays through the recorded data once and then stops. For development and testing, you want continuous playback so the robot keeps streaming data.

Solution

• ReplayConnection now defaults loop=True in its replay config
• Fixed a timing bug in LegacyPickleStore.stream() where looped iterations fired instantly because the reference timestamps were never reset on loop restart. Now detects backwards timestamp jumps and resets timing.

2 files changed, +10 -2

How to Test

dimos --replay run unitree-go2-basic
# Data should continuously loop instead of stopping after ~10s

Contributor License Agreement

• I have read and approved the CLA

[greptile-apps]

Greptile Summary

This PR fixes replay mode so it loops continuously by default instead of stopping after one pass, which is the expected behavior during development and testing. The changes are small, focused, and correct.

Key changes:

• ReplayConnection now defaults loop=True in its replay_config, so all three data streams (lidar, odom, video) loop without requiring an explicit caller opt-in.
• LegacyPickleStore.stream() adds a prev_ts tracker in schedule_emission to detect when the timestamp jumps backwards (indicating a loop restart). On detection it resets start_local_time and start_replay_time to the current wall-clock time and the restarted timestamp, respectively. Without this reset, all messages in every subsequent loop would fire with zero delay because their target_time values would be in the past relative to the still-advancing wall clock.
• TimedSensorReplay (used by ReplayConnection) is confirmed to be a direct alias for LegacyPickleStore via dimos/utils/testing/replay.py, so the timing fix applies exactly where it's needed.

Minor note: The loop-restart detection condition ts < prev_ts relies on timestamps being monotonically increasing within a single recording pass, which is an established invariant for this file format. If a recording ever contained a backwards timestamp mid-pass, it would cause a spurious timing reference reset — but given the format guarantee this is not a practical concern.

Confidence Score: 5/5

• This PR is safe to merge — both changes are minimal, well-scoped, and the timing logic is correct.
• The default-True change is a one-liner with no side effects beyond enabling looping. The timing fix correctly resets the two reference variables (start_local_time, start_replay_time) exactly when needed, and TimedSensorReplay is a direct alias so the fix reaches all affected callers. The existing scheduling pattern is preserved, and no new concurrency issues are introduced.
• No files require special attention.

Important Files Changed

Filename	Overview
dimos/memory/timeseries/legacy.py	Adds prev_ts tracking to schedule_emission to detect loop-restart timestamp jumps and correctly reset start_local_time/start_replay_time; fix is logically sound with a minor edge-case caveat around non-monotonic timestamps.
dimos/robot/unitree/go2/connection.py	One-line default change from None to True for the loop key in replay_config; straightforward and correct.

Sequence Diagram

sequenceDiagram
    participant RC as ReplayConnection
    participant LPS as LegacyPickleStore.stream()
    participant SCHED as TimeoutScheduler
    participant OBS as Observer

    RC->>LPS: stream(loop=True)
    LPS->>LPS: iterate_ts(loop=True)
    LPS->>OBS: on_next(first_data)
    Note over LPS: start_local_time = now()<br/>start_replay_time = first_ts<br/>prev_ts = first_ts

    loop For each message
        LPS->>SCHED: schedule_relative(delay, emit)
        SCHED-->>LPS: emit fires
        LPS->>OBS: on_next(data)
        LPS->>LPS: next_message = next(iterator)
    end

    Note over LPS: End of recording — iterator yields<br/>first msg of next loop (ts jumps back)

    LPS->>LPS: detect ts < prev_ts (loop restart)
    Note over LPS: start_local_time = now()<br/>start_replay_time = ts (reset!)
    LPS->>SCHED: schedule_relative(≈0, emit)
    SCHED-->>LPS: emit fires immediately
    LPS->>OBS: on_next(first_data of loop 2)

    loop Second loop continues with correct timing
        LPS->>SCHED: schedule_relative(delay, emit)
        SCHED-->>LPS: emit fires
        LPS->>OBS: on_next(data)
    end

Loading

_{Last reviewed commit: afff234}