Free Screenly Player with every Business or Enterprise yearly plan. How it works →

October 16, 2026

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

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.