Found on the first run where the payload path had a voice — make test-device against a live PinPointStudio, iPhone 16, 2 September 2026. Invisible before 6a52651 gave the drain loop a log line, because the try? around it turned every throw into "zero bytes sent" and a 20 ms sleep.
What happens
In one 6½-minute run, 86 occurrences:
[ppcp.transfer] transfer pump FAILED libppcp: output buffer too small
(payloadChunk(captureId:index:chunkBytes:data:channel:), DevicePeer.swift:938)
beside 7 908 successful transfer sent 32768 byte(s) this pass, and two of a different kind:
[ppcp.transfer] transfer pump FAILED channelClosed(ChannelCloseReason.failed("posix 89"))
⚠ The bytes still arrive. Clips of 15.6, 18.8, 21.9 and 25.2 MB were announced and queued, the drain kept moving, and the session bundles came out at 81 MB and 82 MB. So this is not a stall — it is a failure that something retries past, roughly once per ninety successful passes.
Why it matters even though nothing visibly breaks
⛔ This is #98's message on the payload path. That issue's cause was libppcp originating nothing over a 64 KiB per-channel queue, and the fix was lowering chunk_bytes to 32 KiB as a recorded deviation from ENC 6f's SHOULD of 262144. At 32 KiB a second chunk queued behind an undrained first would not fit in 64 KiB — which is a plausible reading of these 86, and would make the message back-pressure reported as a malformed-buffer error. That is a guess and is written here as one; it has not been confirmed against the library.
⚠ If that reading is right, the defect is the word, not the condition — and #106's lesson applies: a wrong word in a diagnostic does not merely fail to help, it points somewhere. Someone reading this line while a clip is genuinely missing would go looking at chunk sizing.
What would settle it
- Log the queue depth and the pass budget beside the failure, so "the queue was full" and "the buffer was too small for one chunk" are distinguishable at the point of failure.
- If it is back-pressure: raise it with
libppcp as the successor to F-E1-1 / F-E1-2 — a distinct result code for "would block" — and treat the retry as correct behaviour rather than a workaround.
posix 89 on the pump is a separate question and probably belongs with the residual transport fault recorded in c382888, where the phone sees three channels end cleanly in the same millisecond and Studio sees a broken pipe.
Found on the first run where the payload path had a voice —
make test-deviceagainst a live PinPointStudio, iPhone 16, 2 September 2026. Invisible before6a52651gave the drain loop a log line, because thetry?around it turned every throw into "zero bytes sent" and a 20 ms sleep.What happens
In one 6½-minute run, 86 occurrences:
beside 7 908 successful
transfer sent 32768 byte(s) this pass, and two of a different kind:⚠ The bytes still arrive. Clips of 15.6, 18.8, 21.9 and 25.2 MB were announced and queued, the drain kept moving, and the session bundles came out at 81 MB and 82 MB. So this is not a stall — it is a failure that something retries past, roughly once per ninety successful passes.
Why it matters even though nothing visibly breaks
⛔ This is #98's message on the payload path. That issue's cause was
libppcporiginating nothing over a 64 KiB per-channel queue, and the fix was loweringchunk_bytesto 32 KiB as a recorded deviation fromENC6f's SHOULD of 262144. At 32 KiB a second chunk queued behind an undrained first would not fit in 64 KiB — which is a plausible reading of these 86, and would make the message back-pressure reported as a malformed-buffer error. That is a guess and is written here as one; it has not been confirmed against the library.⚠ If that reading is right, the defect is the word, not the condition — and #106's lesson applies: a wrong word in a diagnostic does not merely fail to help, it points somewhere. Someone reading this line while a clip is genuinely missing would go looking at chunk sizing.
What would settle it
libppcpas the successor to F-E1-1 / F-E1-2 — a distinct result code for "would block" — and treat the retry as correct behaviour rather than a workaround.posix 89on the pump is a separate question and probably belongs with the residual transport fault recorded inc382888, where the phone sees three channels end cleanly in the same millisecond and Studio sees a broken pipe.