Camera disconnects when USB stick gets plugged in

[EtalumaSupport]

SN12064-2026-05-29-080543.zip

[ericweiner]

Need a beta15 retest -- the attached bundle is beta14 (pre-fix)

The attached logs are from 4.0.0-beta14 (build 2026-05-27 15:24). On that build the dart (daA3840-45um) came up at MaxNumBuffer=3 / StaticChunkNodeMapPoolSize=3 -- the old cap. The bundle shows a continuous ~24-minute payload-discard storm from the moment the grab started, ending at 08:02:06 with OnGrabError: "the maximum number of available grab results has been reached -- check MaxNumGrabResults and StaticChunkNodeMapPoolSize." That Camera disconnected line is the grab-pool aborting, not a USB removal -- there is no USB re-enumeration or device-removed event anywhere in these logs.

beta15 (shipped today) raises both MaxNumBuffer and StaticChunkNodeMapPoolSize to 10 -- the exact two settings that abort named. So this specific failure may already be addressed.

Chris, please:

1. Update to the latest beta15 build.
2. Reproduce the USB-stick scenario (plug the stick in while the camera is live-streaming).
3. Attach a fresh log bundle captured right at the moment the camera disconnects.

That tells us two things at once: whether the grab-pool storm still happens now that buffers are 10, and what the USB-stick insertion actually does in the logs (which the beta14 bundle does not capture).

Separately, we are adding graceful recovery so that if the grab thread does stop, you get a clear notification and the app attempts to reconnect instead of freezing the live view silently.

[EtalumaSupport]

Cannot reproduce. Appears similar to when we called you in last week and couldn't reproduce the loss of connection.

[ericweiner]

should we leave this open or close for now? I'm fine with either.

[ericweiner]

Triage / analysis (no fix yet)

Disposition: cannot-reproduce -- parked

Root cause: "camera disconnects when a USB stick is plugged in" did not reproduce for either reporter; it resembles the prior un-reproducible loss-of-connection. The disconnect itself is USB-bus hardware behavior; the fixable part -- graceful recovery/reconnect -- is already covered by the #632 reconnect backoff plus the Pylon-disconnect defense work.

Proposed fix shape: none actionable without a repro. If it recurs, capture a Windows procdump -ma <pid> at the disconnect plus the log bundle.

Cluster: graceful-recovery shares the reconnect path with #632.

Status: analyzed; fix not started; not yet verified on hardware.