Deduced-timestamp bookkeeping can turn a genuine 2 ms interval into 1 ms #149

Hi LabRecorder team,

While validating LabRecorder for PRAYCG, our EEG/EMG/EOG/light-sensor workbench, we reproduced a timestamp round-trip error using synthetic data. I’d appreciate your review of the finding and proposed fix.

Affected code

Our local build is based on LabRecorder v1.17.0, commit 6ee154d3b4213b9c400e8233f023b30284c167ed. The same assignment remains in the current master source inspected on October 6, 2026.

In typed_transfer_loop(), after recognizing a deducible timestamp, the code sets:

last_timestamp = ts + sample_interval;

This leaves the predictor one sample interval ahead of the actual timestamp. A subsequent genuine two-interval step can therefore be incorrectly marked as deduced.

Minimal reproduction

For a nominal 1,000 Hz stream, construct these timestamps using repeated double-precision additions:

dt = 1.0 / 1000.0
t0 = 1_000_000.0
t1 = t0 + dt
t2 = (t1 + dt) + dt

With t0 as the initial explicit timestamp:

• Expected: preserve [t0, t1, t2], including the approximately 2 ms final interval.
• Current writer logic: encodes [t0, 0, 0].
• Raw XDF reconstruction: produces [t0, t1, t1 + dt], reducing that final interval to approximately 1 ms.

The repeated-addition construction matters because the compression condition uses exact floating-point equality.

Proposed correction

- last_timestamp = ts + sample_interval;
+ last_timestamp = ts;

This produces [t0, 0, t2] for the example and preserves all three timestamps.

Recording-test evidence and limitations

An unmodified Windows x64 v1.17.0 CLI recording failed our raw-timestamp comparison despite retaining all 500 expected EMG samples and complete stream footers.

Our locally patched build passed 12 synthetic recording trials—six GUI and six CLI—with synchronization and dejittering disabled during timestamp checks. These covered regular spacing, the two-interval pattern, duplicates, gaps, mixed rates, and both shutdown orders.

For transparency, the local build also contains other changes and uses a different adjacent native LSL DLL. Those recording results are not an isolated one-line binary comparison; the minimal source-level reproduction above isolates the predictor defect.

We retained synthetic XDF files, expected timestamp vectors, logs, and build identities. No participant data is involved, and we are not claiming every existing recording is affected.

I saw the shutdown and clock-offset timeout work in PR #146, so I’m keeping this timestamp-compression report separate.

Could you review the correction and whether a regression test should be added? If this is already tracked, please point me to the existing discussion.

Thanks for maintaining LabRecorder.