RemoteTransfer full-size download silently never completes and latches the whole subsystem into 0x8D03

[takusaito-ctrl]

Environment: ILCE-7M5 · USB · Camera Remote SDK V2.02.00 · linux-arm64 (Raspberry Pi, kernel 6.8.0-1051-raspi) · server 3.0.0

Summary

POST /api/cameras/{id}/sd-card/slot/{slot}/files/{cid}/{fid}/download returns 202, creates a 0-byte file, and then nothing ever happens. There is no completion, no failure, no event, and no timeout. Worse, once one download is stuck, every RemoteTransfer operation for the rest of the session fails with 0x8D03 — including thumbnails and screennails that worked moments earlier.

Reproduction

1. Connect in remote-transfer mode, priority key pc-remote.
2. GET /sd-card/slot/1/files → 326 files, fine.
3. POST /sd-card/slot/1/files/131198/1/download (DSC09989.JPG, 12,565,987 bytes)

{"message":"Download started (remote-transfer)","success":true}   HTTP 202

4. A 0-byte DSC09989.JPG appears. Polled for 35s, still 0 bytes:

t= 5s  size=0
t=10s  size=0
...
t=35s  size=0

5. Any subsequent content request now fails, including previously-working thumbnails:

POST .../131305/1/download   -> 400 {"message":"Failed to start file download: 0x00008D03"}
POST .../131305/1/thumbnail  -> 400 {"message":"Failed to start thumbnail download: 0x00008D03"}

0x8D03 = CrError_RemoteTransfer_GetContentsDataDisable (shared/sdk/include/CrError.h, base CrError_RemoteTransfer = 0x8D00 + offset 3).

Why this is hard to diagnose

The failure is invisible at every layer:

• SDK::GetRemoteTransferContentsDataFile() returns CrError_None — we report 202 in good faith.
• Nothing is written to the server log beyond the request line.
• No SSE event is ever emitted, on any stream.
• There is no timeout, so the pending transfer stays in m_pendingTransfers forever.

Server log for the whole episode is literally just:

Handling request: POST /api/cameras/CFCA6014E092/sd-card/slot/1/files/131198/1/download
⬇️  Download SD Card File: POST /api/cameras/.../131198/1/download

Notes on root cause

Two hypotheses were tested and one was ruled out:

• usbfs buffer limit — ruled out. Sony's Linux docs require usbfs_memory_mb=150; this host defaulted to 16. Raising it to 150 changed nothing, the download still hung at 0 bytes. (Still worth fixing separately as a setup gap, filed on its own.)
• Cross-camera content — untested, still open. Sony's docs for op_pull_out_content_stored_on_media_in_remote_transfer_mode state: "We cannot guarantee the transfer of content taken with other cameras. And large files may not be handled depending on the OS." The failing file's EXIF reads model=ILCE-7M4, software=ILCE-7M4 v5.01 while the connected body is an ILCE-7M5. There are native 7M5 files on the same card (e.g. content_id=131305, 4.17 MB) that would isolate this cleanly — but they cannot be tested in the same session, because step 4 has already latched 0x8D03.

CameraDeviceRest.cpp:526-528 already carries Sony's Linux-specific chunk size, matching their sample verbatim:

CrInt32u divisionSize = 0x5000000;  // 80MB
#if defined(__linux__)
    if (m_connType == cli::ConnectionType::USB) divisionSize = 0x1000000;  // 16MB
#endif

Expected

• A stuck transfer should time out and surface an error to the caller and over SSE.
• One failed transfer must not disable thumbnails/screennails and all later downloads for the session.
• If the SDK genuinely cannot transfer a given file, the 202 is a lie — it should be a 4xx/5xx with the reason.

Knock-on effects

This is the trigger for several other failures, filed separately: the connection lifecycle breaks and ReleaseDevice() hangs at shutdown, ultimately requiring the camera to be physically unplugged.

[takusaito-ctrl]

Correction to the "no timeout" statement above, after reading transferPollLoop().

There is a 120-second timeout at CameraDeviceRest.cpp:1522, but it erases the pending transfer without emitting anything, so the observable behaviour from a client's point of view is unchanged — total silence. My 35-second poll simply never reached it.

Split out as #44 so it can be fixed independently of the root-cause transfer failure.

[jordlee]

Cross-platform result: does not reproduce on macOS — and two of this issue's hypotheses are falsified

Environment: the same ILCE-7M5 body (CFCA6014E092) and the same SD card as the reports above, server 3.0.0, SDK V2.02.00, remote-transfer, priority key pc-remote — but darwin-arm64 (macOS 15) instead of linux-arm64.

Every transfer succeeded

File	content_id	EXIF Model / Software	Size	Result
DSC09989.JPG — the exact file from this issue	131198	ILCE-7M4 / ILCE-7M4 v5.01	12,565,987	✅ complete, < 5 s
DSC09988.JPG	131197	ILCE-7M4 / ILCE-7M4 v5.01	12,825,698	✅ complete, < 5 s
DSC09880.ARW	131082	native	67,792,896	✅ complete, ~20 s
DSC00081.JPG	131305	ILCE-7M5 / ILCE-7M5 v1.00	4,173,653	✅ complete, < 5 s

Four consecutive transfers in one session, no hang, no 0x8D03, thumbnails still working afterwards, clean DELETE/POST /connection at the end (200 in 0.14 s / 3.86 s).

1. Cross-camera authorship — ❌ disproven

The open question in this issue was whether the failure is Sony's documented "we cannot guarantee the transfer of content taken with other cameras". It is not. content_id=131198 is byte-for-byte the file that hangs forever on the Pi, its EXIF confirms ILCE-7M4 v5.01 on a connected 7M5, and it transferred here in under five seconds and verified as a valid 12,565,987-byte JPEG.

Worth recording so nobody repeats it: I first picked DSC09988 as a native control based on the card's creation_year (2025), and it turned out to be 7M4-authored too. Creation date is not a proxy for authorship — only EXIF Model is. That mistake does not affect the conclusion, since trial 1 is the decisive one, but it would quietly invalidate a control-vs-test matrix built the way I originally built it.

2. File size — ❌ disproven

67.8 MB succeeded against a 12.5 MB failure. Also worth noting for anyone reading the "0 bytes at t=35s" evidence: the SDK writes these files at completion, not incrementally — the 67.8 MB transfer also sat at 0 bytes for ~15 s before appearing at full size. A file at 0 bytes therefore does not distinguish "stuck" from "still working"; only the 0x8D03 that follows does.

3. 0x8D03 as a latch — ❌ disproven

0x8D03 (CrError_RemoteTransfer_GetContentsDataDisable) does not latch anything. It means "a transfer is already in progress." Induced deterministically on macOS:

Step	Request	Result
1	POST .../131082/2/download (67.8 MB)	202
2	POST .../131305/1/download, 0.3 s later	400 0x8D03
3	wait for step 1 to finish	—
4	repeat step 2 verbatim	202, completes

So the observation in this issue — "once one download is stuck, every RemoteTransfer operation for the rest of the session fails with 0x8D03, including thumbnails that worked moments earlier" — is the subsystem behaving correctly. The one stuck transfer never completes, so it is permanently "in progress", so everything after it is permanently "busy". There is no second latching bug, and no separate mechanism to go looking for.

This also removes the constraint that made RCA expensive here: 0x8D03 is not a one-way door, so the "one attempt per process" limit does not exist. On a healthy session you can run a whole matrix back to back.

Filed the two consequences separately: #49 (0x8D03 reported as 400 "Failed to start file download" when it is a retryable busy state — this wording is what produced the latch theory) and #50 (transfers are neither queued nor deduplicated).

What is left

One Linux-only defect: the transfer itself hangs. Platform is now the only differentiating variable — same body, same card, same file, same SDK version, same server version, same connection mode. The obvious first suspect is the Linux-only branch already quoted in this issue:

CrInt32u divisionSize = 0x5000000;  // 80MB
#if defined(__linux__)
    if (m_connType == cli::ConnectionType::USB) divisionSize = 0x1000000;  // 16MB
#endif

macOS takes the 80 MB path and works. The cheap next experiment is to force 80 MB on Linux and retry 131198 — that is a one-line change and either implicates divisionSize immediately or clears it and points at the Linux USB transport.

Everything downstream of this — #41, #43, and the total-silence case in #44 — is therefore also Linux-only. Still worth P0 given Linux ships, but it should be scoped as a Linux defect rather than a general one.

(Nothing here weakens the original report — the hang is real and reproducible on the Pi. What changed is the causal model.)