T

leonarski_fandClaude Opus 5 37c9750206 fix: drain the sample camera SUB socket to the newest frame

The SUB socket is strictly FIFO, so once the GUI falls behind at 50 Hz it
stays behind: every recv returns the oldest queued frame and the lag never
recovers on its own. zmq.CONFLATE cannot fix this because it keeps only the
last *part* of a message, which shreds the multipart header+payload frames
the producer sends.

recv_multipart is atomic, though — a non-blocking recv either yields a whole
message or raises Again — so draining in a loop is a multipart-safe conflate.
The drain runs after the previous frame's decode, so it discards exactly the
backlog that built up while we were busy, and the socket is consumed at line
rate regardless of how long a frame takes to decode.

Verified against a real PUB/SUB pair: 100 queued multipart messages collapse
to the newest one with both parts intact, and RCVTIMEO is still honoured when
the queue is empty.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01DVqbXPoeHyqrQq5Vc8EcYP

2026-09-08 11:35:07 +02:00

.gitea

add 3.14 in the ci

2026-08-25 14:47:04 +02:00

.zed

feat: add hostname+user to gui logs

2026-07-06 16:27:08 +02:00

ci: introduce release workflow

2026-07-27 14:44:33 +02:00

docs

docs: udpate cheatsheet formatting

2026-08-04 15:41:29 +02:00