Repository navigation
Fix the camera freeze on capture and run the API on Linux - #7
Merged
Merged
Conversation
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
… Canon.Core Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
On Linux, closing the session after the camera was turned off or unplugged, then releasing it, made the EDSDK terminate the USB connection twice and crash the application (CLinuxPtpHelper::Terminate from EdsRelease). The release closes the session itself; the Canon samples only release it. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
On Linux the EDSDK lists the camera a few seconds after raising the camera added event, so the single attempt made 500 ms later found no camera and the camera was not reconnected. Retry for about 10 s. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The previous fix was not enough: on Linux the SDK closes the session itself while it dispatches the removal of the camera (CEdsCamera::HandleCameraEvent from EdsGetEvent), and releasing the camera closes it again (CEdsCamera::Dealloc). The second close uses an object freed by the first one and crashes in CLinuxPtpHelper::Terminate (traced with gdb). On Linux, a camera that is gone is no longer released; on Windows it still is. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Writing the flash setting (UI lock, Flash_Target, Flash_Firing, UI unlock) while the live view is sent to the PC freezes the EOS R100: every shutter press then answers busy after 5 s, the camera buttons and screen stop responding, and only turning the camera off and on recovers it. With Canon:ForceFlashFiring (default) the API wrote it before every capture, so the first picture of the photo booth froze the camera. Reproduced on Linux with the camera: captures succeed without the flash setting, with the live view, after the live view stopped, and after the flash setting without live view; they fail every time once the flash is written during the live view. The flash is now forced when the camera connects, before the live view starts and before a capture taken without live view. POST /flash pauses the live view while it writes the setting, and the flash state is not read while the live view runs. The live view start is retried on its own, because the camera answers busy for a moment after the flash setting. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
- Force the flash once per live view session: writing it again on every live view start attempt kept the camera busy, so a start retried after a failure could rewrite it in a loop (reconnection with the stream open). - The flash write refuses to run while the live view is active, and the live view is no longer marked stopped when its state cannot be read. - POST /flash restarts the live view only if a client still wants it, and a failed restart no longer replaces the outcome of the flash setting; live view starts wait for it. - Shutdown and internal error events of a camera that is no longer the current one (left to the Linux SDK) are ignored. - Hot plug retries stop when the application stops, and log each attempt. - Changelog, README and CLAUDE.md precisions. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
tools/Test-Camera.ps1 (Windows PowerShell 5.1 or PowerShell 7, with curl) checks the live view, captures, flash changes during the live view and a camera power cycle against the API, starting it with detailed camera logs when needed, and saves the pictures, the results and the API log. Test-Camera.cmd runs it whatever the execution policy. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Canon:ForceFlashFiring(default) wrote it before every capture, so the first picture of the photo booth froze the camera. The flash is now written when the camera connects, once before the live view starts, and before a capture taken without live view;POST /flashpauses the live view while it writes the setting.net10.0, and every P/Invoke loads"EDSDK"(EDSDK.dllon Windows,libEDSDK.soon Linux). Canon.API targetsnet10.0-windows(unchanged release: single-file win-x64, AutoUpdater.NET) andnet10.0(Linux, no automatic update). AddsEDSDK/linux-x64/libEDSDK.so(EDSDK 13.20.21).CLinuxPtpHelper::Terminate, traced with gdb). A camera turned back on was not reconnected: the hot plug connection is now retried for about 10 s.Logging:LogLevel:Canon.Core=Debug) of every EDSDK event and of each capture step, with its result and duration.tools/Test-Camera.ps1(withTest-Camera.cmd) runs the photo booth checks against the API and saves the pictures, the results and the API log.Root cause of the freeze (EOS R100, Linux)
Test plan
dotnet test CanonSDK.sln: 151 passed (Linux). Both targets of Canon.API build with 0 warnings.b79b623withTest-Camera.cmd: 14/14 steps pass (live view, 4 captures, 3 flash changes each followed by a capture, power cycle then capture). The published exe loadsEDSDK.dll.Notes
dotnet runanddotnet publishof Canon.API now need-f net10.0-windows(Windows) or-f net10.0(Linux); the release workflow, the Dockerfile andbuild.batare updated.specs/2026-10-04-linux-edsdk-design.md,specs/2026-10-04-linux-edsdk-plan.md.🤖 Generated with Claude Code