Preserve RRD preview frames and clarify onboard K1 status
This commit is contained in:
@@ -0,0 +1,90 @@
|
||||
# Node K1 preview R10
|
||||
|
||||
The owner installed R9 and physically confirmed START and STOP. Installed
|
||||
readback is Node 0.8.7 / optional K1 0.1.6+private.1, both services running
|
||||
without restarts. The actual service now reports application_authority_available
|
||||
true. This closes the R9 credential-loading gate, not the live-preview gate.
|
||||
|
||||
Private screenshots, Fleet state and timestamps are retained under
|
||||
private/acceptance/k1-node087-20260907-preview-r10. The owner reported malformed
|
||||
RRD notifications, absent camera, misplaced loading feedback and a failed
|
||||
state check after STOP. Cache clearing for these owner attempts was not
|
||||
independently confirmed. The agent issued no hardware actions.
|
||||
|
||||
## Proven defects
|
||||
|
||||
NodeMediaPeers split each binary_stream.read() into 16384-byte SCTP messages.
|
||||
The browser passed each message directly to send_rrd. Installed Rerun SDK
|
||||
0.36.3 documents send_rrd as accepting an RRD file in a byte array, also
|
||||
described by the [upstream LogChannel reference](https://ref.rerun.io/docs/js/0.36.2/web-viewer/classes/LogChannel.html).
|
||||
Native Python reproduction produces a complete RRF2 recording per read;
|
||||
fragments after the first lack that header. The previous transport test used
|
||||
a tiny fake payload and could not expose this defect.
|
||||
|
||||
The journal separately reports missing local camera FFmpeg after first PCL.
|
||||
FFmpeg 6.1.1 is installed at /usr/bin/ffmpeg and is already a declared Debian
|
||||
dependency, but the reviewed resolver requires an explicit configured path
|
||||
outside its macOS development fallbacks. The systemd unit now supplies that
|
||||
path. No resolver fallback, archive ownership or camera activation fence changed.
|
||||
|
||||
The viewer formerly closed the camera channel if an offer preceded camera
|
||||
activation. It now waits up to 45 seconds for the existing producer and sends
|
||||
the MIME metadata immediately before opening its bounded delivery. It does not
|
||||
select or restart a camera and never issues a physical START.
|
||||
|
||||
## Transport and presentation
|
||||
|
||||
missioncore.node-preview/v1 preserves independent payload boundaries with an
|
||||
MCF1 + big-endian length envelope and ordered fragments of at most 16384 bytes.
|
||||
Both sides retain the 8 MiB payload bound. The browser assembles exactly one
|
||||
payload before passing it to the RRD or MSE decoder; incomplete, overflowing
|
||||
or unframed payloads cannot reach Rerun. The peer response must advertise the
|
||||
protocol. Backpressure, two-peer admission, private-only ICE and lease cleanup
|
||||
remain in place. Delivery failures log only channel and exception class.
|
||||
|
||||
The existing vendor contribution remains inside the Fleet/Node sensor slot.
|
||||
The owner's approved composition is control card, centered compact Status
|
||||
card, then a full-width Rerun card with its own expand/restore action. A
|
||||
half-width spatial viewport alongside an empty camera was rejected because
|
||||
it obscured the primary evidence. A camera companion is displayed below the
|
||||
full-width spatial view only after decoded frames arrive. This is domain
|
||||
composition using SettingsCard, Button, IconButton, ActivityIndicator and
|
||||
existing theme tokens; it introduces no generic visual entity or navigation.
|
||||
|
||||
Pending acquisition feedback stays inside the one pending action. Preview
|
||||
messages go to the single Status card. Preview reconnect retries only the
|
||||
disposable media peer, with backoff capped at 30 seconds while the owner keeps
|
||||
the active view open. It never repeats START/STOP or Wi-Fi provisioning.
|
||||
The live-acquisition settings, blueprint, LAB and recorded Rerun profiles are
|
||||
unchanged; shared recorded-viewer host code is unchanged.
|
||||
|
||||
## Follow-up: STOP and read-only verification
|
||||
|
||||
The journal identifies a vanished BlueZ object at add_device_watcher during
|
||||
the owner's explicit Verify. A retained Python BLEDevice is not proof that
|
||||
the native BlueZ object still exists. Before the single read-only GATT connect,
|
||||
Linux now checks its native cache and, only for a vanished object, obtains one
|
||||
fresh advertisement for the same exact address inside the existing status-read
|
||||
arbiter lease (maximum eight seconds). Public scan generations and the selected
|
||||
target remain unchanged. This is a pre-connect refresh, not a retry of a failed
|
||||
connect or write. macOS behavior and provisioning paths are unchanged. Failure
|
||||
to recover that exact address remains fail-closed.
|
||||
|
||||
The completed control phase remains visible as Device stopped while the next
|
||||
control check is pending. Actual state supersedes stale START/STOP command
|
||||
feedback once capture or completion is observed. The initial START journal
|
||||
exception was the existing physical reconciliation fence; it is not relaxed.
|
||||
|
||||
## Validation and remaining gates
|
||||
|
||||
100 Python checks cover real loopback WebRTC transporting a native RRD larger
|
||||
than one fragment without byte loss, delayed camera metadata, Node projection,
|
||||
package lifecycle and existing Bluetooth/status/provisioning regressions. The
|
||||
new explicit read test proves a vanished handle is refreshed before exactly
|
||||
one connect and no GATT write. Native RRD reassembly is also tested in the
|
||||
actual TypeScript decoder boundary, including malformed/oversized/partial input.
|
||||
|
||||
All 801 frontend tests, Core TypeScript and production build pass. Release
|
||||
hashes, installation readback and owner fresh-cache UI acceptance are recorded
|
||||
below when observed. Local synthetic
|
||||
checks do not establish camera decoding or live stream recovery on the BK.
|
||||
Reference in New Issue
Block a user