Adom Bridge

⋯ 1 unchanged line ⋯

@@ -1,6 +1,6 @@ {
   "slug": "adom-bridge",
-  "version": "2.1.170",
+  "version": "2.1.171",
   "type": "app",
   "brief": "Adom Bridge unleashes your AI onto your full PC: full power, full safety. The AI breaks out of the container it runs in and onto your real machine, managing and running your entire laptop as you: launch apps, move files, drive any window, control KiCad, Fusion 360 or your real signed-in browser. Works with any AI, cloud or local (Claude Desktop, Claude Code, Codex), no Hydrogen required. Bridge and its bridges are an operating system for AI, with managed Node and Python runtimes, and a human-only permission system keeps you in charge of every side-effecting command.",
   "description": "Install this package in a cloud or Hydrogen Desktop container, not on the PC. It delivers two things: the Linux adom-bridge-cli (linked onto PATH) and the Claude skill set that teaches an AI every desktop verb (shell, files, screenshots, windows, notifications, KiCad, Fusion 360, browser automation). The CLI drives the Adom Bridge app running on your Windows PC over the relay; the Windows app itself is the separate installer in the Download box, not part of this package. Run adom-wiki pkg update to keep the CLI and skills current.",

@@ -1,6 +1,6 @@ {   "slug": "adom-bridge",-  "version": "2.1.170",+  "version": "2.1.171",   "type": "app",   "description": "Install this package in a cloud or Hydrogen Desktop container, not on the PC. It delivers two things: the Linux adom-bridge-cli (linked onto PATH) and the Claude skill set that teaches an AI every desktop verb (shell, files, screenshots, windows, notifications, KiCad, Fusion 360, browser automation). The CLI drives the Adom Bridge app running on your Windows PC over the relay; the Windows app itself is the separate installer in the Download box, not part of this package. Run adom-wiki pkg update to keep the CLI and skills current.",   "keywords": [

@@ -51,6 +51,10 @@ adom-bridge --target ConfRoomROG desktop_list_windows   # route.via tells you me ```
 
 
+## When the mesh relay will not connect (2.1.171)
+
+`desktop_mesh_status` carries `relayNote` whenever `relayConnected` is false. The commonest cause is an account the Adom mesh relay does not admit: it only lets in accounts whose token (`bridge.mesh.relayToken` in the account's cloud settings) is on its list, and `relayAuth: "none"` means this box has none. Verbs still route through the cloud command relay; only cross-network mesh paths are missing. `mesh_enabled:false` written into config.json by hand now switches the mesh off even when `mesh_mode` says relay (wiki #229).
+
 ## Who is allowed in: per-box trust (2.1.66)
 
 The account directory says which node ids belong to the account. **Trust** says which of

@@ -13,6 +13,8 @@ description: Record the user's screen with Adom Bridge's NATIVE recorder (v2.1.3 - `desktop_record_encoders` lists the codecs this box can hardware-encode: `{codecs:{h264:{available,hardware,encoders:[{name,hardware}]}, h265:{...}}, default:"h264"}`. h264 is the default (most compatible). **HEVC works** too: `codec:"h265"` records an HEVC MP4 (~40% smaller at similar quality; needs a modern player). HEVC uses the GPU path (a D3D11 VideoProcessor makes NV12 for the hardware H.265 encoder), so `gpu:false` is ignored for h265. `fps` is a start arg too.
 - **Choosing a mode (read this before you pass any encoder option):** say nothing and you get the tuned default: peak-constrained VBR, exact length, a still screen costs almost nothing, fast motion stays sharp. Pass `bitrate` only for a hard cap you actually need (a slow disk, a size limit). Pass `quality` only on content you know is not video or noise (no cap in that mode). Pass `codec:"h265"` when the player is modern and you want half the file. The worked examples with measured numbers and the five example clips: https://wiki.adom.inc/adom/adom-bridge/files/docs/recording.md
 - Rate control (v2.1.128, John: fast motion went splotchy under the old bits-per-second cap): the DEFAULT is peak-constrained VBR with a mean of 3x the old resolution-derived target (about 33 Mbit/s at 1440p30, 72 at 4K) and a peak of 2x the mean. A still screen costs almost nothing (measured 0.34 MB for a 14 s still page) and fast motion gets up to the peak instead of smearing (a noise-field stress page: 30 Mbit/s and readable text, where the old 11 Mbit/s CBR was mush). `bitrate` (bits/s) switches to CBR at that rate when you need a hard cap; `maxBitrate` sets the VBR peak; `quality` 1..100 selects constant-quality mode, which the NVENC MFT does NOT cap (185 Mbit/s on the noise page at 75), so only ask for it on content you know. The start reply and status carry `rateControl` (vbr | cbr | quality).
+- A take that goes quiet (v2.1.171, wiki #230): status and stop carry `lastFrameAgoMs` (time since Windows last sent a new frame), `captureItemClosed` (the capture source went away: display change, window closed, graphics reset) and `captureQuiet`, a plain sentence when either looks wrong; the stop `_hint` repeats it. Windows only sends a frame when the picture changes, so a still screen is quiet too: the note says so rather than guessing. For a long demo, record short clips and check a frame from the end of each.
+- Encoder busy (v2.1.171, wiki #232): if the video encoder does not start within 8 s, `desktop_record_start` answers `errorCode: encoder_busy` at once (it used to hang until the caller timed out). Another recorder probably holds the GPU encoder: close it, or pass `gpu:false`, which now really uses the software H.264 encoder. An "encoder sample allocator empty" error mid-take now drops frames (counted in `droppedFrames`) instead of ending the take.
 - The mouse pointer (v2.1.170, wiki #226): `cursor` (default `true`) on `desktop_record_start` and `desktop_record_window_start`. Pass `cursor:false` for an AI-driven demo of a background window: the AI's input does not move the system pointer, so the only pointer in the take would be the USER's, wandering across the window while they do something else. The start reply and status carry `cursorCaptured` (what Windows actually applied). Hiding the pointer needs Windows 10 2004 or newer; on an older build the pointer stays in and `cursorNote` says so.
 - Status carries the encoder's own counters: `encodedFrames`, `encodeBacklog` (received minus encoded), `sinkOutstanding`, `encodeFps`, plus `droppedFrames` (pool empty, or ticks skipped because the encoder was more than 2 s behind). A rising `encodeBacklog` or a low `encodeFps` at a big resolution means the encoder cannot keep up: pass a lower `bitrate` / `fps`, or record a window instead of a 4K monitor.
 - The timeline is WALL-CLOCK EXACT (v2.1.125, wiki #195). Windows Graphics Capture delivers a frame only when the screen content changes, so a still screen yields few frames and a tiny file, and a moving screen yields the full frame rate; the encoded duration equals the take's wall clock in both cases (a frame count far below fps x seconds is normal, not lost time). ab stamps every frame on the take's wall clock and, after the MP4 is closed, rewrites the container's per-frame durations from those stamps (the Media Foundation fragmented-MP4 sink gives the last frame of every 2 s fragment a duration of 1/fps whatever the real gap was, which is what used to shorten still passages). The stop/status payload reports it as `timeline: {repaired, fragments, samples, endBeforeMs, endAfterMs}` (`repaired:false` + `reason:"no fragments"` for the h265 container, which is not fragmented and already carries exact durations). A held frame is re-written at most every 2 s so any player can seek into a long still passage.