LTC Out: Skipped/Duplicate frame numbers

[mungewell]

Following from investigations on #19 we have seen that the LTC Out frame numbers appear to randomly (in-frequently) either skip or duplicate frames numbers. Raising as new bug as this is not related to the 'wake from screensave' and this happens when the PC is 'awake' ('screensave' disabled) and in 'screensave'.

Dataset (already shared) from '13beta1':
20260915_v13beta1_25fps_8192buf.zip

Which has, as example:

I have also seen this with '13beta2'.

[mungewell]

I ran an overnight session with '13beta2' with STC being clocked from incoming MTC (from previously jammed PicoTimecode), whilst PC was in 'screensave'.

This 'skipped/duplicated' behaviour was also seen, but some captures have a 'twist' in that they auto-corrected a few frames later. Don't know if this related to MTC, or whether previous captures have (or just missed) the correction as well.

Note: the last 2 captures took a few seconds to correct.

2026-09-16_21-53-22-1112.sr.txt:Expected: 21:53:20:22 Got: 21:53:20:21
2026-09-16_21-53-22-1112.sr.txt:Expected: 21:53:20:24 Got: 21:53:21:00

2026-09-17_01-22-27-3129.sr.txt:Expected: 01:22:26:06 Got: 01:22:26:05
2026-09-17_01-22-27-3129.sr.txt:Expected: 01:22:26:06 Got: 01:22:26:07

2026-09-17_04-07-00-4716.sr.txt:Expected: 04:06:58:18 Got: 04:06:58:17
2026-09-17_04-07-00-4716.sr.txt:Expected: 04:06:58:20 Got: 04:06:58:21

2026-09-17_05-11-05-5334.sr.txt:Expected: 05:11:03:23 Got: 05:11:03:22
2026-09-17_05-11-05-5334.sr.txt:Expected: 05:11:03:23 Got: 05:11:03:24

2026-09-17_05-17-31-5396.sr.txt:Expected: 05:17:28:06 Got: 05:17:28:05
2026-09-17_05-17-31-5396.sr.txt:Expected: 05:17:28:12 Got: 05:17:28:13

2026-09-17_05-37-57-5593.sr.txt:Expected: 05:37:52:00 Got: 05:37:51:24
2026-09-17_05-37-57-5593.sr.txt:Expected: 05:37:52:02 Got: 05:37:52:03

2026-09-17_05-48-56-5699.sr.txt:Expected: 05:48:52:22 Got: 05:48:52:21
2026-09-17_05-48-56-5699.sr.txt:Expected: 05:48:53:05 Got: 05:48:53:06

2026-09-17_05-50-24-5713.sr.txt:Expected: 05:50:23:03 Got: 05:50:23:02
2026-09-17_05-50-24-5713.sr.txt:Expected: 05:50:23:05 Got: 05:50:23:06

2026-09-17_06-20-16-6001.sr.txt:Expected: 06:20:15:21 Got: 06:20:15:20
2026-09-17_06-20-16-6001.sr.txt:Expected: 06:20:15:23 Got: 06:20:15:24

2026-09-17_06-41-44-6208.sr.txt:Expected: 06:41:41:01 Got: 06:41:41:00
2026-09-17_06-41-44-6208.sr.txt:Expected: 06:41:41:03 Got: 06:41:41:04

2026-09-17_06-45-16-6242.sr.txt:Expected: 06:45:11:05 Got: 06:45:11:04
2026-09-17_06-45-16-6242.sr.txt:Expected: 06:45:12:16 Got: 06:45:12:17

2026-09-17_07-36-55-6740.sr.txt:Expected: 07:36:51:23 Got: 07:36:51:22
2026-09-17_07-36-55-6740.sr.txt:Expected: 07:36:53:03 Got: 07:36:53:04

[mungewell]

Older datasets (Generate -> LTC Out) DO show the 'correction' behavior...

20260915_v13beta1_25fps_8192buf$ cat summary.txt 

2026-09-15_11-45-49-800.sr.txt:Expected: 11:45:45:16 Got: 11:45:45:21
2026-09-15_11-45-49-800.sr.txt:Expected: 11:45:45:22 Got: 11:45:46:02

2026-09-15_13-20-05-1738.sr.txt:Expected: 13:20:03:19 Got: 13:20:03:21
2026-09-15_13-20-05-1738.sr.txt:Expected: 13:20:03:23 Got: 13:20:04:01

20260915a_v13beta1_25fps_8192buf$ cat summary.txt 

2026-09-15_14-18-45-56.sr.txt:Expected: 14:18:39:19 Got: 14:18:39:21
2026-09-15_14-18-45-56.sr.txt:Expected: 14:18:39:22 Got: 14:18:39:23

20260915b_v13beta1_25fps_8192buf$ cat summary.txt 

2026-09-15_21-16-22-1243.sr.txt:Expected: 21:16:18:19 Got: 21:16:18:20
2026-09-15_21-16-22-1243.sr.txt:Expected: 21:16:18:24 Got: 21:16:19:02

[mungewell]

More data sets (repeated from #19), show lots of skipped/duplicate pairs.

With PC in ScreenSave:
20260916_v13beta2_25fps_mtc_8192buf.zip

And with PC awake (screen save disabled):
20260916a_v13beta2_25fps_mtc_8192buf.zip

[fiverecords]

SuperTimecodeConverter_1.9.13-Beta3_Setup.zip
New build attached. I simulated your rig end to end — MTC in, the real encoder, the real decoder, clock drift, MIDI jitter, late callbacks — and it turned up four things, all in this build.

1. A dead band. After any repeated frame, the output could run one frame behind the source indefinitely, because that particular offset read as "close enough". Something else would eventually push it forward, which is what the Expected :24 Got :00 a few frames after each Expected :22 Got :21 was: the repair, not the fault — and why the delay between the two varied from two frames to a second and a half. There is no dead band now.

2. Any one-tick fault was acted on at once. A frame number that's wrong for a few milliseconds, whatever the cause, cost a frame on the wire. A disagreement now has to stand for three frame boundaries in a row before anything is done; a real offset is still corrected within ~120 ms.

3. A callback merely late was treated as a hole. At your 10.7 ms period the re-align threshold was 8 ms, and re-aligning starts a frame part-way through — on a stream that was still perfectly continuous, because a double-buffered driver has a whole period of slack. Your log's gap 9.3 ms entry is one of those. Re-alignment now needs a hole longer than a period and longer than half a frame; shorter ones are absorbed with every frame intact.

4. With MTC as the source, the frame number ran a frame ahead for the ten milliseconds after every sequence. The decoder's sync point is dated a quarter frame ahead (correctly: the value N+2 starts a quarter frame after piece 7 arrives), and two bits of code read that negative "time since sync" with two different rules. One rule now.

And the thing I most want you to have: every correction the output makes is now written to ltc_gaps.log, on the same timeline as the late callbacks — repeated, skipped, snapped, re-aligned, with the frame it was about to send and the position it was comparing against. So when a capture shows a bad frame number, look for a track line at that second. If there is one, it names the mechanism. If there isn't, the wire and the encoder disagree and the interface becomes the suspect. That one distinction is worth more to me than another night of counting.

What I can't promise: I haven't pinned down by simulation what causes the very first repeat in your signature. With this build it no longer leaves the output behind, it can't come from a momentary fault any more, and the log will say what it was.