One asset's probe blowing up must not break the others.

Operator opted out of validation; trust them and don't probe. Critically, last_reachability_check must NOT be set — the API exposes that field

Smoke test for the enriched page-context dict — guards against silent shape regressions in the load/disk/memory/resolution helpers the System

Smoke-test that System Info renders (heading visible, no 5xx) against the values the page actually produced — also the source of the ``system-

When ``internal_auth_token`` returns '' (no secret available in settings or env), the request would be a guaranteed 403 — so the viewer skips

The viewer's job is to send whatever ``internal_auth_token`` yields as a header; the HMAC derivation itself is exercised in ``lib/internal_aut

Best-effort: a server hiccup must not interrupt the asset loop.

Trusting ``https://signage.example.com`` must not implicitly trust ``https://attacker.example``. The trusted-origin allowlist is exact: only t

Backward compat: defaults must not narrow is_active(). ASSET_X carries no play_days/play_time_* overrides, so the new window filter should be

v1.x put writes its own publish; v1_2/v2 share the helper.

QtMultimedia + libavcodec (the ffmpeg-backed Qt 6 media plugin) auto-selects the appropriate decoder at playback time — V4L2 stateless ``rpi-h

For local-file assets the picker should show the basename (e.g. ``WIZARD_VIDEO_BASENAME``) — pasting the full ``/data/anthias_assets/...`` pat

A LAN host is probed like any other — HEAD actually fires. The reachable/unreachable verdict itself is already covered by ``test_url_fails_re

The serializer's write path rejects out-of-range values, but a hand-edited row or a legacy import could leave a junk value in metadata. GET sh

The top-level ``refresh_interval_s`` and the embedded ``metadata['refresh_interval_s']`` must agree on the response — a row with an out-of-ran

Both bounds of the documented 0..REFRESH_INTERVAL_S_MAX range must 400 on write. ``-1`` is the just-below-zero case; ``86401`` catches the typ

Operator-driven refresh_interval_s edits must not stomp on the upload pipeline's metadata keys (original_ext, transcoded, error_message). Pre-

PATCH a single ``refresh_interval_s`` (partial update) onto an existing webpage asset and read the new value back.

0 stores explicitly; the viewer treats 0 the same as a missing key (no auto-refresh). Operators clearing the field from the edit modal POST 0

POST round-trip for the webpage auto-refresh interval. The interval lives inside ``Asset.metadata`` (so the upload pipeline's read-only stanc

A create without ``refresh_interval_s`` reads back as 0 (the "no auto-refresh" default), and ``metadata`` is left as an empty dict so the uplo

The Continue button on a valid token must call validate, then load /api/v2/assets, then transition to the select step with each seed asset ren

The catch-all ``arm64`` DEVICE_TYPE has no entry in the HW decode map (an unknown aarch64 SBC isn't guaranteed to expose a v4l2-request decode

A Rock Pi 4 running the catch-all arm64 image gets its ``{h264, hevc}`` set once ``host:board_subtype=rockpi4`` is published by anthias_host_a

H.264 is accepted on Pi 5 via software decode — the Cortex-A76 handles 1080p H.264 without frame drops, and YouTube rarely serves HEVC so bloc

A 4K upload on a high-RAM board (Pi 5, Pi 4 4GB) is NOT gated by resolution — the low-RAM cap only fires when MemTotal sits below the threshol

1080p HEVC on the same low-RAM board passes the gate — exactly the boundary the on-device measurement said survives.

A 4K HEVC upload on a low-RAM board (codec is in the supported set, but resolution exceeds 1920×1080) is rejected with a resolution-specific m

When the upload fails BOTH the codec gate and the resolution gate (e.g. 4K MPEG-2 on Rock Pi 4 1GB), the codec message wins (codec is the stri

H.264 upload on a Pi 4 (which HW-decodes H.264) is accepted: the row gets codec / dims / fps written into ``metadata`` and ``is_processing`` i

The codec/resolution gate raises ``UnsupportedVideoCodecError`` as a deliberate, operator-facing rejection — not a fault. The video task must

ffprobe failure (codec reported as 'unknown') must reject the upload — we won't pass through a clip we can't certify against the board's HW de

A board that supports H.264 (Pi 4) gets a libx264 recipe — libx264 is significantly faster than libx265 for the operator.

A codec outside the board's HW decode set is rejected. The exception's message names the rejected codec and supported set; its ``recipe`` attr

When the row has no ``metadata.upload_name`` (YouTube downloads, pre-rebrand rows), the recipe uses a stable ``upload<ext>`` placeholder so th

VP9 / AV1 uploads on Pi 5 are still rejected even though H.264 software-decode was added to the Pi 5 codec set. The rejection recipe tells the

Method-level failures from a live webview (or a dead session bus) are not respawn-worthy — they must propagate so the container restart handle

A webview that survives the handshake but dies during the ``loadImage`` D-Bus call must be reaped, respawned with the inline budget, and sent

``view_webpage`` must always call ``setReloadInterval`` after ``loadPage`` — even when the URI is unchanged from the previous tick, since an a

Splash / fallback callers pass no interval, which becomes 0 — the C++ side treats that as "disable the timer", so this is the no-auto-refresh

When the URI matches ``current_browser_url`` we skip the ``loadPage`` D-Bus call (cheap no-op), but ``setReloadInterval`` still has to fire so

Same recovery contract for the ``loadPage`` path — and the auto-refresh timer must still be armed on the respawned process.

An expired windowed asset can never become active again, so it must not keep the cap firing every 60s.

A windowed asset whose start_date is in the future shouldn't drag the cap into the picture — its activeness can't flip until start_date arrive

Partial windows (only one of from/to set) are no-ops in _matches_play_window — has_window_filter() must agree, otherwise the 60s cap fires for