Fix/python memoryleak replay

[bogwi]

Problem

Running dimos --dtop --replay run unitree-go2 causes one of the Python processes to grow in memory. Even if the dimos-viewer was closed midway the replay that would not change anything and the memory would still grow.

The problem was discussed by @leshy and @aclauer .

Previously, the code was doing this:

delay = target_time - current_time
If delay is negative, emit the frame immediately to catch up.
This meant that if the playback fell behind by 0.5 seconds, it would try to emit 500 milliseconds worth of video, lidar, and odometry frames instantly to catch up.

Solution

Re-Anchoring on Delay: Added a death spiral breaker logic. If the stream detects that it has fallen behind by more than 0.2 seconds (200 milliseconds), instead of trying to catch up with an instantaneous stream of frames, it re-anchors the time to the current frame (start_local_time = time.time()).

Precise Blocking Sleep: Replaced the manual chunked time.sleep() loop with threading.Event().wait(delay). This provides single-call sleep mechanism that has practically zero drift, completely preventing the systematic time accumulation over long playbacks, while still allowing instant cancellation if you stop the replay.

[leshy]

hm this bugs me a bit, two things:

1. why would loading messages ever be so slow? we are just decoding sqlite blobs here.
2. why would slow loading of messages ever cause a memory leak? it should only cause us to be too slow, it's a single loop, we are never able to schedule more then one message emission

are we sure it isn't something simpler, like we are not garbage collecting messages after passing them down to subscribers?

[leshy]

yeah, issue was garbage collection
#2025