Fired on its first real run and has fired on every one since — first seen 1 September 2026 (97133f1), and sixteen times in the 2 September device run against a live PinPointStudio.
[ppcp.transfer] transfer announce WITHOUT payload capture 68474074-… — nothing will follow it
[ppcp.transfer] transfer announce WITHOUT payload capture 4d3a4c3f-… — nothing will follow it
[ppcp.transfer] transfer announce + payload queued capture 0285f3b2-… — 18793534 byte(s)
Two of them, then a good one, in every hosted row of the suite — four rows, sixteen announces with nothing behind them, beside four that queued 15–25 MB correctly.
Why this is a defect and not bookkeeping
announce() enqueues a transfer only when a clip provider comes with it. CORE 8.1 makes the bytes follow the announce, so an announce with clip == nil is a Capture the host waits for and never receives. ⛔ From the host that is indistinguishable from a transfer that has not started yet, and the two want opposite responses: one is patience, the other is "ask again" or "give up on this shot".
⚠ It is not obviously wrong in every case, which is why this needs looking at rather than fixing on sight. A Capture over a Stream that has no video — the metadata or audio Streams a Session opens alongside the camera one — legitimately has no payload to follow it, and the host's capture_request in these runs names four Streams. If that is what these sixteen are, then the log line is the thing that is wrong: it is reporting a correct absent Capture in the language of a fault.
What would settle it
- Print the Stream and its kind beside the capture id. If every one of these is a non-video Stream, this closes as a logging correction; if any is the camera Stream, it is a lost clip.
- Check it against the
absent path — I10 / 8.4b make an absent Capture legitimate, and 6c4b3f6 gave the refusals real reasons (not_retained versus outside_buffer). An announce with no payload should be carrying one of those reasons rather than nothing.
⚠ Related but distinct from #119: that one is a transfer that fails loudly and retries; this one is a transfer that was never enqueued at all.
Fired on its first real run and has fired on every one since — first seen 1 September 2026 (
97133f1), and sixteen times in the 2 September device run against a live PinPointStudio.Two of them, then a good one, in every hosted row of the suite — four rows, sixteen announces with nothing behind them, beside four that queued 15–25 MB correctly.
Why this is a defect and not bookkeeping
announce()enqueues a transfer only when a clip provider comes with it.CORE8.1 makes the bytes follow the announce, so an announce withclip == nilis a Capture the host waits for and never receives. ⛔ From the host that is indistinguishable from a transfer that has not started yet, and the two want opposite responses: one is patience, the other is "ask again" or "give up on this shot".⚠ It is not obviously wrong in every case, which is why this needs looking at rather than fixing on sight. A Capture over a Stream that has no video — the
metadataoraudioStreams a Session opens alongside the camera one — legitimately has no payload to follow it, and the host'scapture_requestin these runs names four Streams. If that is what these sixteen are, then the log line is the thing that is wrong: it is reporting a correctabsentCapture in the language of a fault.What would settle it
absentpath —I10/ 8.4b make an absent Capture legitimate, and6c4b3f6gave the refusals real reasons (not_retainedversusoutside_buffer). An announce with no payload should be carrying one of those reasons rather than nothing.⚠ Related but distinct from #119: that one is a transfer that fails loudly and retries; this one is a transfer that was never enqueued at all.