docs/raspberry-pi.md
Rama main · réplica de lectura del repositorio original.
# Running on a Raspberry Pi
Yes — with caveats worth knowing before you start, because two of them will
decide whether this is a good idea for your venue.
There are two different jobs a Pi can do here, and they have almost nothing in
common. Pick the one you mean.
| | |
| ------------------------------------------- | -------------------------------------------------------------------------------------------------------- |
| [**Pi as a display**](#a-pi-as-a-display) | It sits behind a screen and plays what it is told. Cheap, quiet, entirely sensible. |
| [**Pi as the server**](#a-pi-as-the-server) | It runs the backend, database, queue and FFmpeg for the whole venue. Possible, and the caveats are real. |
---
## A Pi as a display
This is the easy one and the Pi is good at it. A display runs the player, which
is a web page: any Pi from the 3B+ onwards with a browser in kiosk mode works,
and a Pi Zero 2 W manages still images.
```bash
sudo apt install chromium-browser unclutter
```
Start Chromium pointed at your player URL, full screen, with the cursor hidden:
```bash
chromium-browser \
--kiosk \
--noerrdialogs \
--disable-infobars \
--disable-session-crashed-bubble \
--check-for-update-interval=31536000 \
https://player.example.com
```
The screen shows a six-digit pairing code; claim it in the dashboard and it
starts playing. Everything after that is the same as any other display — see
[screens.md](screens.md).
Worth setting up alongside:
- **Auto-start** — a systemd user service or your desktop's autostart entry, so
a power cut brings the screen back without a keyboard.
- **No screen blanking** — `xset s off -dpms`, or the equivalent in your
compositor. A signage display that sleeps is a black rectangle.
- **`cage` or plain X with no window manager** rather than a full desktop; less
to go wrong, less to update.
Video playback is the one thing to test on your own footage. A Pi 4 or 5 decodes
H.264 in hardware and plays 1080p comfortably; 4K is a different conversation,
and Chromium's hardware decoding support on the Pi has historically been
uneven. If video stutters, re-encode your content to 1080p first — the platform
already transcodes to H.264 for exactly this reason.
---
## A Pi as the server
Possible, and people do it. The images are built for it; what decides whether
it is a good idea is what you ask it to encode.
### The images are built for the Pi
Every image is published as a multi-architecture manifest covering `linux/amd64`
and `linux/arm64`, each built natively rather than emulated. `podman pull`
resolves the right one on its own, so nothing about the installation differs
from any other host:
```bash
podman pull ghcr.io/flo-schilli/mynextscreen/backend:0.11.0
```
Check what a tag actually contains:
```bash
podman manifest inspect ghcr.io/flo-schilli/mynextscreen/backend:0.11.0
```
A 32-bit OS is the one thing that will not work — the images are `arm64`, not
`armhf`. `uname -m` must say `aarch64`.
Building on the Pi yourself still works if you want to, and is the path for a
fork that does not publish images:
```bash
git clone https://github.com/Flo-Schilli/mynextscreen.git
cd mynextscreen
npm run images:build
```
Expect that to take a while: it installs the full dependency set and compiles
two Angular applications.
### Transcoding is CPU work, and the Pi 5 made it harder
Uploads are transcoded with FFmpeg, and live streams are transcoded
continuously. Neither uses hardware acceleration on a Pi:
- The **Pi 4** has an H.264 hardware encoder reachable through V4L2 M2M. This
project does not use it — it calls FFmpeg with software encoding for
predictable output across platforms.
- The **Pi 5 has no H.264 hardware encoder at all.** It gained a better CPU and
lost the encoder block, which is the opposite trade from the one you want
here.
Check what your board actually offers:
```bash
ffmpeg -hide_banner -encoders | grep -i v4l2
```
What that means in practice:
- **Uploads** are a one-off cost. A few minutes of 1080p video will take several
times its own length to transcode. Annoying, not fatal; the dashboard shows
progress and the rest of the system stays usable.
- **Live streams are the real limit.** A continuous 1080p encode will occupy a
Pi 5 almost entirely. Set `MAX_CONCURRENT_LIVE_STREAMS=1` and do not plan a
venue around more than one.
If live streaming matters to you, put the server on something with an x86 CPU or
a GPU and keep the Pis as displays.
### Sizing
| | |
| ----------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Board** | Pi 5 with 8 GB, or Pi 4 with 8 GB. 4 GB works for a handful of screens with no live streaming. |
| **OS** | 64-bit Raspberry Pi OS (or any arm64 Linux). A 32-bit image cannot run these containers. |
| **Storage** | **An SSD over USB 3, or NVMe on a Pi 5.** Not an SD card. PostgreSQL's write pattern and a growing media library will wear a card out, and a corrupted card takes the venue's schedule with it. |
| **Network** | Wired. Every display holds an open SSE connection and pulls media over HTTP. |
| **Cooling** | Active. Sustained FFmpeg work will thermally throttle a passively cooled Pi, which turns a slow transcode into a much slower one. |
### Setup
Everything in [installation.md](installation.md) applies unchanged — including
the Ansible playbook, which is written for rootless Podman and pulls the same
images. There is no Pi-specific branch to follow.
For development, `npm run dev` works as it does anywhere: the compose file names
no architecture and every image it pulls has an arm64 build.
### Backups matter more here
A Pi under a bar is likelier to lose power than a rented server. The database
holds every screen, playlist and schedule you have built:
```bash
ansible-playbook download_db.yml
```
Media lives on the filesystem and is not in that dump — back it up separately.
---
## Would I recommend it?
**As displays: yes, without reservation.** That is what the hardware is for.
**As the server: for a small venue with a handful of screens, images and
pre-encoded video, yes.** It will sit there and work.
**Not if live streaming is part of the plan.** That is the one workload where
the Pi has no headroom and no hardware to fall back on, and discovering it
during a show is the wrong time.