{"product":"anthias","releases":[{"date":"2026-09-22","entries":[{"areas":[],"breaking":false,"content_html":"\u003cp\u003ePut Anthias behind a reverse proxy or a tunnel and large videos used to fail to upload, even though\neverything else worked. Anthias puts no limit on how big an upload can be, but the proxy usually\ndoes: Cloudflare\u0026#39;s Free and Pro plans, for example, cap a request at 100 MB, which a few minutes of\nvideo clears easily. From Anthias 2026.09.0, Add asset \u0026gt; Upload file sends a file larger than\n16 MiB in 16 MiB pieces, one after another, and the device puts them back together. Each piece\nclears the proxy on its own. Smaller files upload in one request, as before.\u003c/p\u003e\n\u003cp\u003eA piece that fails on a dropped connection or a server error is sent again, up to 2 more times, so\none hiccup doesn\u0026#39;t throw away an upload you\u0026#39;ve been waiting on. A file Anthias won\u0026#39;t accept, such\nas an unsupported type, is refused on the first piece rather than after the whole file has gone\nup. An upload you abandon halfway is cleaned up once it has sat for an hour without a new piece.\u003c/p\u003e\n\u003ch2 id=\"changing-the-piece-size\"\u003eChanging the piece size\u003c/h2\u003e\n\u003cp\u003eIf your proxy\u0026#39;s limit is lower than 16 MiB, ask for smaller pieces. Add \u003ccode\u003eupload_chunk_size_mb\u003c/code\u003e\nunder \u003ccode\u003e[main]\u003c/code\u003e in \u003ccode\u003e~/.anthias/anthias.conf\u003c/code\u003e, which survives upgrades, and restart Anthias. On\nbalena, set the \u003ccode\u003eANTHIAS_UPLOAD_CHUNK_SIZE_MB\u003c/code\u003e device variable in the dashboard instead. If both\nare set, \u003ccode\u003eanthias.conf\u003c/code\u003e wins.\u003c/p\u003e\n\u003cp\u003eThe value is in MiB (1 MiB is 1,048,576 bytes), from 1 to 24. A value outside that range is moved\nto the nearest limit, a decimal is rounded down, so 8.5 becomes 8, and anything that isn\u0026#39;t a number\nis ignored in favor of the default of 16. Each request carries a little more than the piece itself,\nso leave some room under your proxy\u0026#39;s limit.\u003c/p\u003e\n\u003ch2 id=\"a-failed-upload-says-why\"\u003eA failed upload says why\u003c/h2\u003e\n\u003cp\u003eBefore, almost every upload failure showed the same generic message, asking you to check the file\nand try again. Now the message points at the cause:\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003eA file the server or a proxy refuses as too large says it exceeds the upload size limit of the\nserver or a proxy in front of it, so you know to look at the proxy rather than the file.\u003c/li\u003e\n\u003cli\u003eIf a proxy refuses even a single piece, the message tells you to lower the upload chunk size.\u003c/li\u003e\n\u003cli\u003eA connection that drops mid-transfer says so, and suggests a smaller file too, because some\nbrowsers report a proxy\u0026#39;s size refusal as a dropped connection.\u003c/li\u003e\n\u003cli\u003eIf the last piece went up and no reply came back, the message says the upload may have finished\nand to check the asset list before uploading again, since a second attempt would make a\nduplicate.\u003c/li\u003e\n\u003cli\u003eA page that has gone stale asks you to reload it and try again.\u003c/li\u003e\n\u003cli\u003eA server error points you to the device logs.\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch2 id=\"for-developers\"\u003eFor developers\u003c/h2\u003e\n\u003cp\u003eUploads through the API, \u003ccode\u003ePOST /api/v1/file_asset\u003c/code\u003e and \u003ccode\u003ePOST /api/v2/file_asset\u003c/code\u003e, are written to\ndisk as they arrive instead of being read into memory first. The content endpoints in API v1 and v2\n(\u003ccode\u003eassets/\u0026lt;id\u0026gt;/content\u003c/code\u003e) stream their response too, where they used to hold several copies of the\nfile in memory. In the project\u0026#39;s testing on a Raspberry Pi 3 B+, fetching a 150 MB asset through\nthe content endpoint ran the server out of memory, and the API stayed down for about 40 seconds\nwhile it restarted. After the change, the same request added about 12 MB to the server\u0026#39;s memory.\u003c/p\u003e\n\u003cp\u003eThe content endpoints return the same JSON as before, with the file as base64 in \u003ccode\u003econtent\u003c/code\u003e. For\nfile assets the response is now always \u003ccode\u003eapplication/json\u003c/code\u003e, so the browsable API page no longer\nrenders them.\u003c/p\u003e\n","description":"A video bigger than your reverse proxy's request limit, such as Cloudflare's 100 MB cap on its Free and Pro plans, now uploads instead of failing. When an upload does fail, the message names the cause.","title":"Large uploads work behind a proxy, and a failed upload says why","type":"improvement","url":"https://www.screenly.io/releases/anthias/2026.09.0/large-uploads-behind-a-proxy/"},{"areas":[],"breaking":false,"content_html":"\u003cp\u003eFrom Anthias 2026.09.0, you can drag images and videos from your desktop and drop them anywhere on\nSchedule Overview, including the asset list, the navigation bar and the margins, and they upload.\nUntil now only the upload area inside Add asset took a drop. A file dropped anywhere else made the\nbrowser open the file itself and leave the page.\u003c/p\u003e\n\u003cp\u003eWhile you drag, the page shows \u0026quot;Drop to upload\u0026quot;. When you let go, Add asset opens on Upload file\nand shows the progress there, \u0026quot;File 2 of 5\u0026quot; for example, then closes when the last file is in. If\na batch is already uploading, the page says \u0026quot;Upload already in progress\u0026quot; instead, and you can drop\nthe new files once it finishes. While another dialog is open, such as Edit asset or a preview, a\ndrop doesn\u0026#39;t upload, and a message asks you to close the dialog first.\u003c/p\u003e\n","description":"Images and videos dragged from your desktop upload wherever you let go on Schedule Overview. Before, only the upload area inside Add asset took a drop, and a file dropped anywhere else opened in the browser and took you off the page.","title":"Files dropped anywhere on Schedule Overview upload","type":"improvement","url":"https://www.screenly.io/releases/anthias/2026.09.0/drop-files-anywhere-on-schedule-overview/"},{"areas":[],"breaking":true,"content_html":"\u003cp\u003eIf you only use the web interface in a browser, nothing changes for you. This only matters if you\nturned on authentication and run a script or dashboard of your own that listens for the web\ninterface\u0026#39;s live updates: from Anthias 2026.09.0, it has to sign in first.\u003c/p\u003e\n\u003cp\u003eThe web interface keeps the asset list current through a WebSocket connection at \u003ccode\u003e/ws\u003c/code\u003e. When\nauthentication is turned on, Anthias 2026.09.0 accepts that connection only from a browser with a\nsigned-in session, the same rule every page of the web interface already follows. A browser you\nuse the web interface in is already signed in, so nothing changes there. If you run Anthias without\nauthentication, which is the default, \u003ccode\u003e/ws\u003c/code\u003e stays open as before.\u003c/p\u003e\n\u003cp\u003eTurning authentication on or off, or changing the username or password, closes the open\nconnections. The web interface reconnects by itself and has to pass the new settings to get back\nin.\u003c/p\u003e\n\u003cp\u003eIf you run Anthias with authentication on, upgrade to get this.\u003c/p\u003e\n\u003cblockquote\u003e\n\u003cp\u003e\u003cstrong\u003eIf this affects you:\u003c/strong\u003e with authentication on, a script, dashboard or other client that opens\n\u003ccode\u003e/ws\u003c/code\u003e without signing in is refused from 2026.09.0, with a 403 at the handshake. Username and\npassword sent as HTTP Basic credentials aren\u0026#39;t accepted on \u003ccode\u003e/ws\u003c/code\u003e either, even though the API\nstill takes them. Sign in through the web interface\u0026#39;s login page and send the session cookie you\nget with the handshake.\u003c/p\u003e\n\u003c/blockquote\u003e\n","description":"With authentication on, Anthias 2026.09.0 sends the web interface's live updates only to signed-in browsers. Your browser keeps working as before, but a script or other client that listens on /ws without signing in is refused.","title":"Live updates in the web interface need a signed-in session","type":"security","url":"https://www.screenly.io/releases/anthias/2026.09.0/live-updates-need-a-signed-in-session/"},{"areas":[],"breaking":false,"content_html":"\u003cp\u003eA backup you download from the Settings page now holds your settings and content and leaves out\nhalf-finished uploads, and a restore stops before changing anything if the backup\u0026#39;s database is\nnewer than the player can read. If you turned on HTTPS, keep your own copy of its certificate,\nbecause backups no longer include it.\u003c/p\u003e\n\u003cp\u003eFrom Anthias 2026.09.0, \u0026quot;Get backup\u0026quot; and \u0026quot;Upload \u0026amp; recover\u0026quot;, under Backup \u0026amp; restore on the Settings\npage, work only with what Anthias runs on: the settings file \u003ccode\u003eanthias.conf\u003c/code\u003e, the database, the\n\u003ccode\u003ebackups\u003c/code\u003e folder of database dumps, the default assets list and your content. Before, a backup took\neverything in \u003ccode\u003e~/.anthias\u003c/code\u003e and \u003ccode\u003e~/anthias_assets\u003c/code\u003e. Other files that sit in \u003ccode\u003e~/.anthias\u003c/code\u003e, such as\nthe certificate and key that \u003ccode\u003ebin/enable_ssl.sh\u003c/code\u003e installs in \u003ccode\u003e~/.anthias/ssl\u003c/code\u003e, are no longer put in\na backup, and a restore won\u0026#39;t write them back. If you rely on those, keep your own copy.\u003c/p\u003e\n\u003cp\u003eHalf-finished uploads and downloads in the content folder are left out too. They can be gigabytes\nof something nobody finished sending, and they only made the archive bigger.\u003c/p\u003e\n\u003ch2 id=\"restores-check-the-version\"\u003eRestores check the version\u003c/h2\u003e\n\u003cp\u003eEach backup now records the Anthias release and the version of the database it came from. A backup\nwhose database is newer than the restoring Anthias understands is refused before anything is\nwritten, with a message to upgrade Anthias to at least the release that made it. A backup from an\nolder version restores, and its database is brought up to date right after. Backups made before\n2026.09.0 carry no version, so they count as older and still restore.\u003c/p\u003e\n","description":"A backup from Anthias 2026.09.0 holds your settings, database and content, and leaves out half-finished uploads that only made it bigger. A restore turns down a backup whose database is newer than it understands, before writing anything, and tells you which release to upgrade to.","title":"Backups carry only what Anthias needs, and restores check the version","type":"improvement","url":"https://www.screenly.io/releases/anthias/2026.09.0/backups-and-restores/"},{"areas":[],"breaking":false,"content_html":"\u003cp\u003eEvery upgrade pulls a fresh image for each Anthias service, and until now it left the previous ones\non the card. The installer\u0026#39;s cleanup only removed untagged layers, so the old tagged images stayed,\nand a device that had upgraded a handful of times carried several full copies of Anthias. One\nperson who asked for a fix found the last 6 releases taking about 16 GB on their devices. Removing\nthem took the cards from 76% full to 26%.\u003c/p\u003e\n\u003cp\u003eFrom Anthias 2026.09.0, the installer and \u003ccode\u003ebin/upgrade_containers.sh\u003c/code\u003e remove the old images as their\nlast step, once the new containers are running. If the pull or the start fails, the old images stay\nin place to fall back on.\u003c/p\u003e\n\u003cp\u003eOnly Anthias images are removed (\u003ccode\u003eghcr.io/screenly/anthias-*\u003c/code\u003e, plus the older \u003ccode\u003escreenly/anthias-*\u003c/code\u003e\nand \u003ccode\u003escreenly/srly-ose-*\u003c/code\u003e names), and only those no container uses, running or stopped. Tagged\nimages for other containers you run on the same machine are left alone. Untagged leftovers, which\nnothing can use, are pruned as the installer already did. Each removal is printed as \u0026quot;Reclaimed\nsuperseded image\u0026quot; followed by the image name, and a device with nothing to clean prints nothing.\u003c/p\u003e\n\u003cp\u003eTo clear the leftovers from earlier releases without waiting for the next upgrade, run\n\u003ccode\u003e~/anthias/bin/purge_stale_images.sh\u003c/code\u003e. It\u0026#39;s safe to run at any time.\u003c/p\u003e\n","description":"Each upgrade now deletes the Anthias images of the release it replaced once the new one is running, so old releases stop piling up on the card. One person found 6 old releases taking about 16 GB, and a script clears the ones already there.","title":"Upgrades remove the old Anthias images they replace","type":"improvement","url":"https://www.screenly.io/releases/anthias/2026.09.0/upgrades-remove-old-images/"},{"areas":[],"breaking":false,"content_html":"\u003cp\u003eOn a board short of memory, the screen could freeze, or the whole board could stop responding\nuntil someone power cycled it. Anthias 2026.09.0 changes how both cases end.\u003c/p\u003e\n\u003ch2 id=\"running-out-of-memory\"\u003eRunning out of memory\u003c/h2\u003e\n\u003cp\u003eWhen memory runs out, the viewer container is meant to be what the system stops, because Docker\nthen restarts it clean. Before, only the small script that starts the viewer was marked to go\nfirst, and stopping it freed almost nothing. In the project\u0026#39;s testing on a 2 GB board with an\nRK3566 chip, the system stopped that script twice in a row, got back less than 200 KB each time,\nand still had to stop something else. Every process in the viewer container is now marked, so the first thing\nstopped is the viewer itself, and in the same test that freed about 100 MB at once.\u003c/p\u003e\n\u003ch2 id=\"a-board-that-stops-responding\"\u003eA board that stops responding\u003c/h2\u003e\n\u003cp\u003eWhen you install or upgrade with the installer, it now sets up systemd\u0026#39;s watchdog with a 30 second\ntimeout, so a board whose system hangs reboots by itself. Which watchdog it uses depends on the\nboard:\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003eRaspberry Pi boards use the Pi\u0026#39;s hardware watchdog. Raspberry Pi OS already had it switched on\nwith a 1 minute timeout, and Armbian and Debian ship it off.\u003c/li\u003e\n\u003cli\u003eOn x86, any hardware watchdog the machine exposes is used, and the kernel\u0026#39;s software watchdog\notherwise.\u003c/li\u003e\n\u003cli\u003eOther boards, such as the Rock Pi 4 and the NanoPi R3S, use the software watchdog. In the\nproject\u0026#39;s testing, the hardware watchdog on both of those boards halted the board instead of\nrestarting it, and it stayed dark until someone power cycled it. The software watchdog\nrestarted the Rock Pi 4 within about 30 seconds.\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003eA board with no watchdog that can restart it gets the watchdog switched off explicitly, rather than\nleft to the system default. A reboot that hangs while shutting down is forced through after 5\nminutes.\u003c/p\u003e\n","description":"When memory runs out, Anthias 2026.09.0 makes sure the viewer is what gets stopped and restarted, and the installer sets up a watchdog that reboots a board whose system hangs, instead of leaving it dark until someone power cycles it.","title":"Boards recover on their own when memory runs out or the system hangs","type":"improvement","url":"https://www.screenly.io/releases/anthias/2026.09.0/recovery-from-memory-exhaustion/"},{"areas":[],"breaking":false,"content_html":"\u003ch2 id=\"fixes\"\u003eFixes\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eAdd asset opens with an empty form every time. The URL of the last web asset you added no longer\nsits in the box, one press of Enter away from a duplicate, and the Apps tab starts from the list\nof apps instead of the last app\u0026#39;s form.\u003c/li\u003e\n\u003cli\u003eThe Actions column in the asset table fits its buttons, so the icons no longer spill past the\nedge of the table.\u003c/li\u003e\n\u003cli\u003eGoing from a video or a web page to an image shows less black screen. While the image loads, the\nscreen holds the last image Anthias showed instead of going black.\u003c/li\u003e\n\u003cli\u003eOn Docker Compose installs of boards other than the Raspberry Pi, System info shows the board\u0026#39;s\nname, such as FriendlyElec NanoPi R3S LTS, instead of \u0026quot;Generic aarch64 Device\u0026quot;. The\n\u003ccode\u003edevice_model\u003c/code\u003e field of \u003ccode\u003e/api/v2/info\u003c/code\u003e, which was empty on these boards, now has the name too.\u003c/li\u003e\n\u003cli\u003eWhen Anthias can\u0026#39;t identify the board and so can\u0026#39;t check a video\u0026#39;s codec, the upload message\nsays what to check: on Docker Compose installs, that \u003ccode\u003eanthias-host-agent\u003c/code\u003e and Redis are running.\nIt used to tell you to re-flash with a board-specific image that doesn\u0026#39;t exist.\u003c/li\u003e\n\u003cli\u003eInstalling on Raspberry Pi OS Trixie no longer fills the output with Ansible deprecation\nwarnings.\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch2 id=\"for-contributors\"\u003eFor contributors\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eThe Ansible playbook reads gathered facts through \u003ccode\u003eansible_facts\u003c/code\u003e, and the new\n\u003ccode\u003eansible/ansible.cfg\u003c/code\u003e sets \u003ccode\u003einject_facts_as_vars = False\u003c/code\u003e, so a bare fact reference fails\ninstead of slipping back in. That file takes precedence over \u003ccode\u003e/etc/ansible/ansible.cfg\u003c/code\u003e when the\ninstaller runs the playbook.\u003c/li\u003e\n\u003cli\u003eNew tests cover chunked uploads and their error messages, page-wide drag and drop, and the Add\nasset reset. A fake \u003ccode\u003edocker\u003c/code\u003e command tests the image cleanup, and an Ansible test runs the\nwatchdog selection against made-up sysfs trees, which is how the x86 case is covered.\u003c/li\u003e\n\u003cli\u003eThe repository has an MJML newsletter template in \u003ccode\u003eemails/\u003c/code\u003e, with a CI job that validates it and\nchecks the compiled size against Gmail\u0026#39;s clipping limit.\u003c/li\u003e\n\u003cli\u003eThe Anthias website adds pages on free digital signage software and on Yodeck and piSignage,\nexpands the Raspberry Pi pages, and links to the Screenly shop for buying a player.\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003eDjango moves from 5.2.14 to 5.2.17, which brings its upstream security fixes, along with the usual\nPython, JavaScript and GitHub Actions dependency updates.\u003c/p\u003e\n","description":"Add asset opens with an empty form every time, boards other than the Raspberry Pi show their own name on System info, and the installer no longer floods its output with Ansible warnings on Raspberry Pi OS Trixie.","title":"Less black screen when a video gives way to an image, and other fixes","type":"roundup","url":"https://www.screenly.io/releases/anthias/2026.09.0/fixes-and-improvements/"}],"json":"https://www.screenly.io/releases/anthias/2026.09.0/v1.json","product":"anthias","product_label":"Anthias","url":"https://www.screenly.io/releases/anthias/2026.09.0/","version":"2026.09.0"}],"title":"Anthias 2026.09.0","url":"https://www.screenly.io/releases/anthias/2026.09.0/","version":1}