Anthias 2026.10.0 | Screenly

Anthias 2026.10.0: The background worker stops killing its own processes

Fri, 16 Oct 2026 00:00:00 +0000

On a board short of memory, Anthias kept stopping and restarting parts of itself, which cost the board time and memory it didn't have. It was the largest single problem in the crash reports Anthias devices send the project. Anthias 2026.10.0 stops it, and upgrading is all you need to do.

Anthias runs uploads, downloads, video probing and housekeeping in a background worker, the anthias-celery container. That worker kept killing its own idle processes and starting replacements. Its log filled with lines like these:

Process 'ForkPoolWorker-3' pid:412 exited with 'exitcode 1'
Timed out waiting for UP message from <ForkProcess(ForkPoolWorker-4, started daemon)>

The trigger was the soft time limit, the warning a task gets before its hard limit cuts it off. On a busy board that warning could arrive after the task had already finished, and the idle process that received it exited. From Anthias 2026.10.0, a warning that arrives when no task is running, or that was meant for an earlier task, is ignored. A task that really runs past its soft limit is still stopped, and one that hangs is still cut off by its hard limit.

The tasks that read the display's power state over HDMI-CEC and send telemetry could also catch the warning meant for them, carry on, and get killed by the hard limit. They now stop when they're told to.

Anthias 2026.10.0: Restoring a backup no longer corrupts or locks up the database

Fri, 16 Oct 2026 00:00:00 +0000

Restoring a backup from the Settings page could leave Anthias with a database it couldn't read, or one so locked that the web interface answered with server errors. A player upgraded from an older install could hit the second one too. Anthias 2026.10.0 fixes both, and backups made by earlier versions still restore.

Both problems were in the one SQLite database where Anthias keeps its assets and settings, ~/.anthias/anthias.db, which the web server, the background worker and the viewer all use at once.

Backups and restores

"Get backup", under Backup & restore in Settings, used to put the database in the archive together with its write-ahead log files, anthias.db-wal and anthias.db-shm, each read at a different moment while Anthias kept writing. "Upload & recover" then unpacked the archive over the live files. When the archive carried no log of its own, the old database's log stayed next to the restored database, SQLite replayed it into the wrong file, and the first read after the restore failed with database disk image is malformed.

Now a backup carries a single copy of the database, taken through SQLite at one moment, with everything in the log included and no log files beside it. A restore deletes the log files of each database it replaces before anything opens it.

Backups made before 2026.10.0 still restore. Their log files are skipped, which avoids the corruption but leaves out any changes that were still only in the log when the backup was made.

If the database can't be copied while its log holds changes that aren't in the main file yet, the backup now fails, and the "Get backup" download ends in an error, instead of producing an archive without those changes.

A database that hasn't switched to write-ahead logging

Anthias runs the database with write-ahead logging, so reads and writes don't block each other. It used to ask SQLite to switch to that mode every time it opened a connection. On a database that wasn't switched yet, such as one from an older install or one just restored, the switch needs the file to itself, and with 3 services using it the request failed with database is locked. Each failure left a file open, and the web interface answered with server errors. In the project's crash reports, one device went from database is locked to Too many open files to unable to open database file in a single afternoon.

Now each service checks the mode once when it starts, and switches it if it can. If the database is busy, Anthias carries on in the old mode, which is slower when several services write at once but works, and tries again at the next start.

Anthias 2026.10.0: Media that takes too long to process no longer stays on Processing

Fri, 16 Oct 2026 00:00:00 +0000

While Anthias prepares an upload or downloads a video, the asset shows "Processing" in the asset table. If that fails, the row shows "Failed", and clicking it opens the asset with the reason. Anthias 2026.10.0 fixes the cases where a slow job never got that far.

Jobs that run too long

Five of these jobs had only a hard time limit: reading a video's duration, preparing an image, preparing a video, downloading from YouTube and downloading a video from a URL. One that ran over was killed on the spot with no chance to update the asset, so the asset stayed on "Processing" with nothing to say why.

From Anthias 2026.10.0, each of them gets a warning 30 seconds before its hard limit and stops cleanly. An image or video that runs out of time while being prepared or downloaded shows "Failed" with a message such as "Timed out: processing did not finish within 270s". A video whose duration can't be read in time leaves "Processing" without a message. The limits themselves are the same as before: 2 minutes to read a video's duration or prepare a video, 5 minutes to prepare an image, and 15 minutes for a download.

Images over the size limit

Anthias refuses images over 50 megapixels. An image between 50 and 100 megapixels already said so, in a message written for developers. One over 100 megapixels, such as a large scan or a poster export, failed with the image library's own warning about a possible "decompression bomb DOS attack", which sounds far worse than an image that's too big. Now both say how big the image is, that the limit is 50,000,000 pixels, and to resize it and upload again.

Expected failures stop looking like crashes

A YouTube link that YouTube refuses (a 403 or 404, an age restriction, a region block), an image over the limit, and a source file that's gone by the time processing starts, for example because you deleted the asset while it was processing, are expected outcomes. The worker log now records them as a single line instead of an error with a traceback, and they're no longer sent as crash reports. If you point crash reporting at your own Sentry project with SENTRY_DSN, they stop showing up there too. The asset table shows the same as before: a YouTube refusal still shows "Failed" with YouTube's reason, and a deleted asset is gone.

Anthias 2026.10.0: The viewer starts more reliably after restores, slow boots and display restarts

Fri, 16 Oct 2026 00:00:00 +0000

The viewer is the container that puts content on the screen. Anthias 2026.10.0 fixes 4 ways it could get stuck starting up.

On a slow first boot, or right after a restore, the viewer could ask for the asset table before the database had its tables. It failed with no such table: assets and the container restarted into the same race. The viewer now waits until the database is fully set up, and logs Database is not migrated yet; delaying viewer startup every 30 seconds while it waits.
If an earlier display process was still holding the anthias.viewer name on the session bus, every new attempt to start one failed within half a second, and the viewer spent all 30 of its attempts on the same failure. In the project's testing on a Pi 5 that was close to 7 minutes of black screen. The viewer now finds the old process, asks it to exit, forces it if it won't, and starts the new one.
On the boards that run the Wayland compositor (Pi 5, x86 and arm64), the viewer used to treat a leftover socket from a compositor that had died as a running one, and gave up before the compositor came back. It now connects to the socket and waits until the compositor answers.
Changing "Screen rotation" or "Prefer dark mode" in Settings restarts the display process. The viewer now waits for the old one to exit before loading the next asset, instead of sending the asset to a process that was on its way out and stalling until it dropped off.

Clearer errors when the display process won't start

When the display process dies before it finishes starting, the viewer's error now says how it ended, such as killed by SIGSEGV (-11). Before, it ended on whatever the process last printed.
On the Pi 5, x86 and arm64 images, a display process that can't register on the session bus exits with status 1 and says which registration failed. It used to crash with SIGSEGV on the way out, which looked like a crash in the display process.
A display process that crashes now prints a stack trace on every board, which the viewer's error includes when the crash happens during startup. Before, only the 64-bit Pi 3 image printed one.

Anthias 2026.10.0: Players showing the same playlist drift apart less

Fri, 16 Oct 2026 00:00:00 +0000

Two screens in a shop cycling the same menu board in German and English used to drift apart, until after a few hours they switched languages seconds apart. The player started an asset's countdown only after it had refreshed the schedule, read the database and told the display to load the asset, so each rotation took the asset's duration plus that overhead, and the overhead differs from one device to the next.

From Anthias 2026.10.0, the countdown starts when the rotation does, so an image or web page with a 30 second duration rotates 30 seconds after its rotation began. If loading takes longer than a short asset's duration, the player moves straight on to the next one. The viewer log shows the wait next to the duration, for example Sleeping for 29.8 of 30s.

A video's duration is its length, so the overhead now comes off the end of the clip instead: the last fraction of a second can be cut, more on a slow board. Stopping a video still adds time to each rotation, so a playlist with videos still drifts, more slowly than before. In the project's testing on a Pi 2 with a mixed playlist, drift went from about 36 seconds an hour to about 28.5.

Players still don't line up with each other: each one starts its playlist when it boots.

Anthias 2026.10.0: The upgrade script no longer runs a Pi 2 or Pi 3 out of memory, and other fixes

Fri, 16 Oct 2026 00:00:00 +0000

Fixes

Running bin/upgrade_containers.sh yourself on a board with less than 1.5 GiB of memory, such as a Pi 2 or Pi 3, now stops the viewer and the background worker before pulling new images, and starts them again on the new ones. Pulling with the viewer running could use up memory and swap and reset the board halfway through. The screen shows no content during the pull, and the web interface stays up. Upgrades through the installer already stopped every container first.
A memory card whose product name contains a byte that isn't valid UTF-8 no longer stops storage health monitoring, which the storage card on the System Info page relies on.
Starting the viewer no longer logs /proc/<pid>/oom_score_adj: No such file or directory.

For contributors

A test fails the build if a background task has a hard time limit without a soft one below it, and another fails it if a module the viewer imports pulls in celery, which the viewer image doesn't ship.
New tests cover the soft time limit handling, the database readiness wait, the viewer's startup and respawn paths, and SQLite backup and restore.

Python, JavaScript and GitHub Actions dependencies are updated.