mirror of
https://github.com/Screenly/Anthias.git
synced 2026-06-10 09:08:09 -04:00
7f8bbe43d7
* feat(install): generic-arm64 best-effort support (Armbian on Rock Pi, Orange Pi, …) Wires up a `generic-arm64` device_type so the installer recognises any aarch64 host that isn't a Raspberry Pi and runs the same Anthias stack on it. Closes #2849 (Tier 1). * `bin/install.sh::set_device_type` + `bin/upgrade_containers.sh` get an `aarch64` fallback branch, INTRO_MESSAGE / unsupported-message copy refreshed, raspberry-pi-tagged ansible tasks skipped on generic-arm64 (same as x86), vchiq strip extended. * ansible: validated set in `site.yml`, `docker_arch_by_device_type` gains `generic-arm64: arm64`. `docker-buildx-plugin` added to the apt-install list — required for MODE=build with `--platform=` Dockerfiles, harmless on pull-mode boards. Pre-existing host_agent service unit hardcoded `~/installer_venv/bin/python` (an ephemeral tmpdir post-#2843); split into a persistent `~/.anthias-venv` that ansible syncs before installing the unit. * image_builder: `generic-arm64` build target, Qt6 + cage + wayland like x86; `va-driver-all` deliberately *not* shipped — Rockchip / Allwinner / Amlogic mainline hwdec goes through V4L2 M2M / request API, not VAAPI, so mesa-va-drivers would be dead weight. * viewer: `start_viewer.sh` reuses the x86 cage path for generic-arm64; `media_player.py` routes generic-arm64 to MPV (the `device_helper.get_device_type()` fallback returns 'pi1' on non-Pi aarch64 hosts, so the proxy needs the DEVICE_TYPE env override that pi4-64 already uses). New test added. * host_agent: `SUPPORTED_INTERFACES` gains `end` prefix — Rockchip GMAC etc. surface as `end0` on systemd predictable naming, which was previously filtered out, leaving the splash page stuck on "Detecting network…". * CI: docker-build matrix + mirror-latest-tags publish `latest-generic-arm64` alongside the existing per-board tags. * Docs: README, marketing site supported-hardware table, and FAQ get a plain-language "Yes, on a best-effort basis" entry that spells out the software-decode trade-off, the SoCs known to work well (RK3399 / RK35xx / Allwinner H6 / Amlogic GXBB-GXL-GXM / S905X3), and the boards to avoid (Allwinner H616 / H618). Per-SoC hardware decode (`rkmpp`, `cedrus`, `meson-vdec`) is the planned Tier-2 follow-up. Validated end-to-end on a Rock Pi 4B (Armbian trixie, RK3399, 1GB RAM) via build-on-device: install completes, web UI reachable, all four asset types (image, H.264 1080p60, H.265 1080p60, webpage) cycle through the viewer cleanly, mpv pure-decode benchmark shows 0 dropped frames over the full 60s of each clip. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * fix(ansible-lint): pair become with become_user on .anthias-venv sync task ansible-lint's partial-become rule fires on `become_user:` without a matching `become:` at the same level, even when the play-level become already covers it. Explicit pairing keeps lint quiet without changing runtime behaviour. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * fix: address Copilot review feedback on generic-arm64 PR - ansible: drop `creates:` guard on the runtime venv sync — `uv sync` is idempotent (sub-second resolver check when nothing changed), so re-running unconditionally means dependency updates from a pyproject.toml / uv.lock change actually land on upgrade instead of silently skipping. Idempotency surfaced via `changed_when` keyed on uv's `+/-/~` package-action prefix so steady-state runs stay `ok`. - ansible: rework docker-buildx-plugin comment to justify the install on its own merits (any MODE=build run needs it because of `FROM --platform=$BUILDPLATFORM` in Dockerfiles) rather than tying it to generic-arm64 lacking published tags — that explanation becomes stale the moment this PR merges and CI publishes them. - viewer: `get_alsa_audio_device()` short-circuits on `DEVICE_TYPE=generic-arm64` before the Pi-firmware dispatch, since the Rock Pi / Orange Pi / Banana Pi class of board has none of the `vc4hdmi*` or `Headphones` ALSA cards. Defers to ALSA's `default` device; operators with a non-standard sink can override via `~/.asoundrc` (already bind-mounted into the viewer container). - tests: new assertions that generic-arm64 routes mpv through `--vo=gpu --gpu-context=wayland` and `--audio-device=alsa/default`. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * fix(website): disambiguate Debian release codenames in supported-hardware copy Copilot flagged the previous wording — "running Raspberry Pi OS, Debian, or Armbian (Trixie or Bookworm)" — as misleading: the parenthetical reads as if Raspberry Pi OS and Armbian are themselves "Trixie or Bookworm", but those are Debian codenames, and Armbian builds can also be Ubuntu-based. Split the sentence so the codenames are tied explicitly to Debian. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * fix(ansible): derive is_raspberry_pi from device_type, not architecture Copilot caught that the `is_raspberry_pi` helper in docker.yml was defined as `ansible_architecture in ['aarch64', 'armv7l', 'armv6l']`, which is also true on generic-arm64 (Rock Pi / Orange Pi / …). That silently applied the Pi-only `gpio` group to non-Pi SBCs. device_type is the authoritative discriminator and is validated upstream in ansible/site.yml's pre_tasks, so use it directly. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * refactor: rename device_type generic-arm64 → arm64 (parallel to x86) Per review feedback: `generic-arm64` was the original working name for the new aarch64 non-Pi fallback. `arm64` is shorter and parallels `x86` — both are architecture-generic device_types that catch any host without a board-specific image, sitting alongside the per-board labels (pi2 / pi3 / pi4-64 / pi5). User-facing prose still says "generic 64-bit ARM" or "Armbian on Rock Pi / Orange Pi / …" for context. Mechanical s/generic-arm64/arm64/ across install scripts, ansible, image_builder, viewer / start_viewer, host_agent, tests, CI matrix, mirror-latest-tags, Dockerfile.viewer.j2, README. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * review polish on arm64 PR - viewer: get_alsa_audio_device's arm64 short-circuit now logs the registered ALSA cards (from /proc/asound/cards — aplay isn't in the viewer image) once per process when DEVICE_TYPE=arm64, so an operator reporting "no HDMI audio" carries enough breadcrumbs in journalctl alone to pick the right ~/.asoundrc override. - ansible: rewrite the docker-buildx-plugin size claim — 15 MB download / 67 MB extracted, from the deb metadata on arm64. - viewer: MediaPlayerProxy.get_instance comment block split into a two-bullet rationale, calling out the pi4-64 and arm64 cases separately so a future reader doesn't mistake the lead sentence for "pi4-64-only". - install.sh / upgrade_containers.sh: spell out that the aarch64 catch-all in set_device_type is intentional — a future Pi model whose model string drifts past the regexes lands here too, trading software decode + no Pi-boot tweaks for a louder fail. - README + FAQ: tighten the Plymouth caveat from "few seconds of black" to "kernel boot log scrolls until the viewer takes over", which is what actually happens on most U-Boot ARM SBCs. - ansible: rename the docker.yml var from `is_raspberry_pi` to `device_is_pi` now that it's derived from device_type rather than `ansible_architecture`, so the name matches what it does. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * docs: narrow arm64 support to Debian-based Armbian (call out Ubuntu) Copilot flagged that "Armbian" in the new docs is ambiguous — Armbian builds come in both Debian-based (Bookworm/Trixie) and Ubuntu-based (Jammy/Noble) flavours. The installer's ansible role wires Docker's apt repo under download.docker.com/linux/debian/{{ ansible_distribution_release }}, which 404s on the Ubuntu codenames, so an Ubuntu-Armbian user following the current docs would hit a broken install at the very first `apt update`. Narrowing the wording in README, the marketing site's supported-hardware blurb, and the FAQ to "Debian-based Armbian" so users pick the right image. Extending the installer/playbook to handle Ubuntu-based Armbian is a separate follow-up. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
259 B
259 B
title, description, layout
| title | description | layout |
|---|---|---|
| Get Started - Anthias Digital Signage | Install Anthias on Raspberry Pi, x86 PC, or generic 64-bit ARM SBC (Rock Pi, Orange Pi, Banana Pi…). Pre-built disk images, one-line installer, and balenaHub options. | get-started |