[Bug]: Android device panel shows "No video received" instead of the hub's "ffmpeg not found" error

[charsijawaan]

Before submitting

• I searched existing issues and did not find a duplicate.
• I included enough detail to reproduce or investigate the problem.

Area

apps/web

Steps to reproduce

1. On Linux, run the T3 server with ffmpeg unavailable to the device hub. Without uninstalling ffmpeg: set SERVE_EMU_FFMPEG=/nonexistent/ffmpeg for the server (e.g. a systemd drop-in for the t3 service) and restart it.
2. Open the Device panel and select an Android emulator.
3. Wait about 15 seconds.

Expected behavior

The panel says ffmpeg is missing or unusable, the reason the device hub already reports.

Actual behavior

The panel shows "No video received from the device. Reconnect to try again." Nothing in the panel or the server trace mentions ffmpeg.

The hub's Android API does report the cause:

GET /vendor/serve-emu/api/stream-mode?device=emulator-5554 → 503
{"ok":false,"error":{"code":"service_unavailable","message":"ffmpeg not found or unusable (tried \"/nonexistent/ffmpeg\"): spawn /nonexistent/ffmpeg ENOENT"}}

In packages/client-runtime/src/device/stream.ts, a non-OK video response becomes throw new Error(`stream ${response.status}`) without reading the body (line 657 on main). The panel then falls through to the first-frame timeout (FIRST_FRAME_TIMEOUT_MS, 15s) and shows the generic message.

Impact

Minor bug or occasional failure

Version or commit

t3 v0.0.43-nightly.20260927.2344 (bundled expo-device-hub 0.12.0)

Environment

Ubuntu 26.04.1 LTS, T3 background service (systemd), Node 24.21.0, Android emulator 37.1.11

Logs or stack traces

GET /vendor/serve-emu/api/stream-mode?device=emulator-5554 -> 503
{"ok":false,"error":{"code":"service_unavailable","message":"ffmpeg not found or unusable (tried \"/nonexistent/ffmpeg\"): spawn /nonexistent/ffmpeg ENOENT"}}
GET /vendor/serve-emu/api/stream-settings?device=emulator-5554
{"ok":false,"error":"serve-emu start for emulator-5554 is cooling down after a failure"}

Screenshots, recordings, or supporting files

No response

Workaround

Install ffmpeg (e.g. sudo apt install ffmpeg) and restart the T3 server. Investigated with Claude Code.

[juliusmarminge]

Triage

Confirmed on current main. The Android panel never sees the hub's ffmpeg error, so after 15 seconds it shows the generic first-frame message. This is not the iOS stream.avcc path.

expo-device-hub 0.12.0 (what T3 pins) defaults Android capture to grpc-screenshot. That mode calls assertFfmpeg before a session is published. With SERVE_EMU_FFMPEG unset or pointing at a missing binary, startup throws ffmpeg not found or unusable (tried "…"): …, which is the 503 body on GET /vendor/serve-emu/api/stream-mode. A later start during the hub's cooldown only returns serve-emu start for <serial> is cooling down after a failure, so the ffmpeg text exists only on the request that actually failed.

The Device panel does not call that endpoint. It opens /vendor/serve-emu/ws. In hub 0.12.0, attachEmuSocket does router.ensure() and on failure calls socket.close() with no code and no reason, discarding the error. createDeviceStreamClient treats that close as a transient disconnect (connectAndroid in packages/client-runtime/src/device/stream.ts): it retries, and the first-frame timer started in connecting() is not reset. After FIRST_FRAME_TIMEOUT_MS (15s) it always fails with "No video received from the device. Reconnect to try again." DeviceStreamView only renders detail once status is error, and that string replaces any close reason. The test "does not extend the first-frame deadline each time a socket reconnects" locks this in: a close reason of restart still becomes "No video".

Line 657 (throw new Error(`stream ${response.status}`)) is readIosVideo. Android never fetches that body. Patching it would not surface this error.

Not a duplicate of #12229 or its open PR #12237 (keyframe handshake and capture source) or #12639 (that recovery work is what added this 15s generic timeout). Still present on main; no newer release fixes it.

A useful fix has to read the startup error from the attempt that failed. Polling stream-mode after the socket has already died usually hits the cooldown string instead. Either the hub should close the socket with the error (123-byte WebSocket reason limit), or the client should learn the failure from the start call itself and fail immediately with that message instead of waiting out the first-frame timer.