CrError_Connect_TimeOut (0x8208) is reported as "Camera refused the connection" — points at camera settings instead of the USB link

[jordlee]

Symptom

A connect failure caused by a bad USB link (camera behind a USB hub) surfaced as:

Camera refused the connection (0x00008208)

0x8208 is CrError_Connect_TimeOut — the SDK timed out establishing the PTP session. "Refused" reads as the camera actively said no, which sends you to credentials, control mode, and remote-shooting settings. The real fix was plugging the camera directly into the machine instead of through the hub.

Cause

CrError_Connect_TimeOut has no case of its own and falls into default::

https://github.com/crsdk/alpha-sdk-api/blob/main/api/server/src/CameraWebController.cpp#L705-L713

The switch handles the three SSH auth codes specifically and lumps everything else under "Camera refused the connection". That default is a reasonable catch-all for genuine refusals (FailRejected, FailUnspecified), but it is actively misleading for the transport-level codes.

Impact

The most common physical failure mode — marginal USB link (hub, cable, port) — is reported as a camera-side rejection. Nothing in the message hints at the link, so diagnosis starts in the wrong place. In our case it cost a full round of config investigation before the hub was suspected.

Suggested fix

Give the transport/state codes their own cases, in the same specific style as the SSH ones:

• CrError_Connect_TimeOut (0x8208) — name the link: "Timed out establishing the session. If the camera is on a USB hub, try a direct port; otherwise check the cable. For a network body, confirm remote shooting is enabled."
• CrError_Connect_FailBusy (0x820A) — camera busy / another client holds the session
• CrError_Connect_SessionAlreadyOpened (0x820D) — a session is already open

Worth a look alongside #38: both make a connect failure describe something other than what happened, and they compound — #38 hides the code entirely, this one mislabels it once it is visible.

Environment

macOS 15 (arm64), ILCE-7M5, main @ 4e1927a. Reproduced through a USB hub; resolved by connecting directly.

[jordlee]

Reproduced on macOS — and the trigger is far more common than a bad USB link

Environment: ILCE-7M5 (CFCA6014E092) · USB · SDK V2.02.00 · darwin-arm64 · server 3.0.0

Reproduced 3/3, deterministically, with no hub involved. Any second process attempting to connect a camera another process already holds gets:

HTTP 400 {"message":"Camera refused the connection (0x00008208)","data":{"error_code":"0x00008208"}}

That reframes the priority. This issue reads as a marginal-hardware case (hub, cable, port), but process contention is an everyday occurrence: the MCP extension's server plus a manually started one, two sessions at once, or a leftover process still holding the camera. I hit this state twice by accident in a single afternoon of work on this repo.

With auth supplied it compounds:

Camera refused the connection (0x00008208). Check the access-authentication
username, password and fingerprint.

Both halves are wrong — the cause is "another process has the camera", and the advice sends you to credentials.

A third code needs its own case: 0x8219

Not in this issue's list. After a SIGKILLed server left its USB session open, connecting in remote-transfer produced:

Camera refused the connection (0x00008219)

0x8219 is CrError_Connect_RemoteTransfer_NotSupported (index 27 from base 0x8200 in shared/sdk/include/CrError.h). It means the camera cannot enter remote-transfer mode right now — not that anything was refused. Connecting the same camera in remote mode a moment later succeeded.

Suggested cases, updated

Confirmed only three SSH codes have their own case in CameraWebController.cpp; every other connect error falls to the default:. Worth adding:

• CrError_Connect_TimeOut (0x8208) — the highest-value one. Name both plausible causes: another process on this machine already holds the camera, or the USB link (hub/cable/port). Both produce this code.
• CrError_Connect_RemoteTransfer_NotSupported (0x8219) — the camera cannot enter remote-transfer now; suggest remote, or a clean disconnect/reconnect cycle.
• CrError_Connect_FailBusy (0x820B) and CrError_Connect_SessionAlreadyOpened (0x8210) as originally proposed — note the values, since the enum has CrError_Reconnect_TimeOut and two Reserved entries interleaved, so they are not where a naive count puts them.

The default: should probably also stop appending the credentials hint unless the code is actually SSH-related.