docs(wiki): DS-2CD1047G3H-LIU main-stream ISAPI snapshot is a firmware bug — camera line to be replaced

Full live investigation of the persistent 503 "deviceBusy" on main-stream ISAPI
snapshots (10.0.10.13): ruled out config (byte-identical to a working sibling
model), ruled out firmware age (reproduced on both the original V5.8.11 and
current V5.11.0 builds, ~15 months apart), and ruled out real resource
contention (a full channel-ID sweep shows every ID fails identically except
the one hardcoded working value, including nonexistent channels) — pointing
at a broken/incomplete ISAPI snapshot handler that mislabels itself as
"busy," not a real encoder ceiling.

RTSP main-stream frame-grab was confirmed as a working route around it, but
given the bug and the sub-stream's real-world plate-read accuracy problems,
the owner decided to replace the DS-2CD1047G3H-LIU units rather than carry
an ffmpeg/RTSP dependency to work around vendor firmware. Ingested the
vendor datasheet as a source page along the way.

Claude-Session: https://claude.ai/code/session_01FWncR69HgGPuei1dLrW3cU

wiki/log.md

@@ -2619,3 +2619,57 @@ scanning (blocked on secure-context TLS for LAN phones + weak Code128-via-camera
 QR-on-ticket first) and a Tauri v2 Android merchant app (native ML Kit scanning via the official
 barcode-scanner plugin; deferred over Android build/distribution overhead + the
 configurable-server-URL prerequisite). Full analysis on [[validation-discounts]].
+
+## [2026-08-23] ingest | HIKVISION DS-2CD1047G3H-LIU-F datasheet
+
+Vendor datasheet dropped in `raw/DS-2CD1047G3H-LIU.md`. Key new fact: main stream on this model
+supports H.265+/H.265/H.264+/H.264 only — **no MJPEG**; sub-stream adds MJPEG. Likely mechanical
+explanation for the persistent ISAPI main-stream snapshot 503 (`deviceBusy`) already logged on this
+model in [[lpr-camera]] (2026-06-26/27): the on-demand JPEG snapshot has no native path on main,
+so it has to transcode from H.264/H.265 live, which this SKU's firmware apparently can't do
+reliably at 2560×1440. Bitrate spec (32Kbps–16Mbps) also confirms the site's main-stream config
+(6144–12288Kbps) was never out of range — rules out misconfiguration definitively.
+
+## [2026-08-23] query | Main-stream 503: model-specific or config? RTSP as a workaround?
+
+Live-compared two Hikvision units at park-buzi via their public port forwards
+(`park-buzi.msai.al:8081`/`:8082`) plus the `:8082` unit directly on the LAN (`10.0.10.13`).
+Channel-101 (main) config is **byte-identical** between a working `DS-2CD1043G2-LIU` (8081, 200 OK)
+and the failing `DS-2CD1047G3H-LIU` (8082 / `10.0.10.13`, persistent 503 `deviceBusy`, 3/3 retries
+instant) — same resolution/bitrate/framerate/SmartCodec state. Rules out config as the cause;
+confirms it's model/firmware-specific (matches the datasheet finding above). Then tested RTSP
+(`rtsp://…@10.0.10.13:554/Streaming/Channels/101` via ffmpeg, TCP transport) against the SAME
+failing camera: returned a valid 2560×1440 JPEG on the first try. RTSP taps the continuously-
+running encode rather than asking for an on-demand re-encoded JPEG, so it sidesteps whatever the
+ISAPI snapshot path chokes on. Not yet built into `camera.ts` (would add an `ffmpeg` child-process
+dependency + RTSP auth/transport handling) — filed as a viable, proven fallback if full-resolution
+main-stream stills are ever needed; sub-stream ISAPI snapshot remains sufficient for current ANPR
+use. Full comparison table + RTSP command on [[lpr-camera]].
+
+## [2026-08-23] update | Firmware update tested and ruled out; sub-stream confirmed too weak for ANPR — RTSP is now required
+
+Two developments on the DS-2CD1047G3H-LIU (`10.0.10.13`) main-stream 503: (1) the owner reports the
+sub-stream (768×432) **fails to read plates "from time to time"** in real use — sub-stream-only is
+no longer an acceptable mitigation, it's an accuracy problem. (2) Before building RTSP, tested
+whether this was a day-one firmware bug: the camera's original `V5.8.11`/250415 build was confirmed
+(via Hikvision's own release note) to be the FIRST H13U firmware to support this camera family at
+all. Upgraded live to `V5.11.0`/260701 (~15 months newer, spanning an intermediate release that
+explicitly claimed "image stability" fixes). Result: **no change** — identical `deviceBusy` 503,
+5/5 attempts, post-upgrade. Firmware is now a ruled-out cause, not a theory; this looks like a real
+encoder/hardware ceiling on this SKU. Next step: build the RTSP-based main-stream capture path into
+`packages/devices/src/drivers/camera.ts` (not yet started). Full detail on [[lpr-camera]].
+
+## [2026-08-23] update | Root cause nailed down: broken ISAPI handler, not "busy" — decision to REPLACE the camera line
+
+Final test on the DS-2CD1047G3H-LIU snapshot 503: swept every channel/stream ID against
+`GET .../channels/<id>/picture`, including nonexistent ones (1, 100, 103, 201, 999). Every single
+ID returns the identical `503 deviceBusy` body EXCEPT exactly `102` (the real sub-stream), which is
+always 200. A real busy/saturated encoder would not succeed on one specific value while failing
+garbage IDs identically — this is a generic fallback error: the firmware's snapshot handler is only
+correctly wired for channel 102, and everything else (valid main-stream 101 included) falls through
+to a stock, mislabeled "Device Busy" response. Confirms the firmware-upgrade non-result from
+earlier today (a wrong-code-path bug wouldn't be fixed by more capacity). Owner's decision: replace
+the DS-2CD1047G3H-LIU units rather than carry an RTSP/ffmpeg workaround dependency — the sibling
+DS-2CD1043G2-LIU (no such bug, ISAPI main-stream snapshot works natively) is the reference model
+going forward. RTSP main-stream capture remains documented as a proven, viable fallback if a G3H
+camera is ever unavoidable, but is not being built. Full sweep table + reasoning on [[lpr-camera]].