Two numbers from the 28 Aug preview run: absent ≈ present, and 828 frames against ~1500 captures

[liversedge]

From PinPointStudio's preview handover, 28 August 2026, §4.5 — two numbers from the 28 August device run that neither end should assume belong to the other.

The run

600+ segments in one run, tapped == sent, host counters climbing, zero decode failures. Preview works. These are the two things in it that nobody can yet explain.

1. absent segments roughly equal present ones

10 fps taken from a 240 fps sensor means the other 230 frames were deliberately not retained, and 5.11c3 says non-retention is announced absent and is never a gap. So this is correct — and it also doubles the announce rate for a viewfinder, which is the one thing on the link that runs continuously.

⚠ Worth deciding whether it is intended, or whether a preview Stream should coalesce its non-retention into one absent per interval rather than one per skipped frame. A decision, before it is a change — and it touches #107's territory, since announce rate is what fills the transfer table.

2. Their frames (828) runs well below present captures (~1500)

With zero decode failures. So it is not corrupt payload arriving — it is payload that never completes, or an assembly that drops what completed.

⛔ Could be either end:

Ours	Theirs
Payload completion — a chunk sequence begun and not finished, e.g. shed or superseded before the last chunk goes out	Assembly — a complete chunk set that never becomes a frame

⚠ Neither of us should assume it is the other. The cheapest instrument is the one that already exists: segmentsSent on our side against their capt/frames, read at the same moment on the same run.

Exit criterion

Both numbers explained. Item 1 either accepted as intended or turned into a change with a stated rate; item 2 attributed to one end and an issue raised there. Not closed by agreeing it is probably fine.

[liversedge]

The rate changed underneath both numbers — 8e8f947, 28 August

Preview now runs at 30 fps, not 10 — previewProfileId is 640x360@30, and PpcpDeclaration.previewRateMillihertz and PreviewFrameTap.intervalNs are one number expressed twice so the declaration cannot drift from the tap.

⚠ Neither number in this issue survives that unchanged, so a re-read is needed before either can be attributed.

Item 1 — absent ≈ present

The arithmetic moves the wrong way. At 10 fps off a 240 fps sensor, 230 of every 240 frames were non-retained. At 30 fps it is 210 of 240 — the ratio improves, but the absolute announce rate triples, and announce rate is what fills the transfer table (#107). ⛔ This is now three times the announce rate and three times the payload on the one link that runs continuously, sustainable only because libppcp reclaims transfer entries as of a9785bb — on the old library it would have exhausted the 128-entry table in four seconds instead of thirteen.

So the decision this issue asks for — one absent per interval, or one per skipped frame — is worth more now than when it was filed, not less.

Item 2 — 828 frames against ~1500 captures

Untouched, and still unattributed to either end. ⚠ The cheapest instrument is still the one that already exists: segmentsSent on our side against their capt/frames, read at the same moment on the same run. That run has not happened and the 30 fps change means the old pair of numbers cannot be reused.

⚠ PpcpLog now exists (8201ec8), so this reading can be taken off a cabled phone from a Linux or Windows host rather than only from Xcode — which is what makes a same-moment joint reading practical at all.

Exit criterion unchanged. Not closed by agreeing it is probably fine.