Free self-hosted signage for 3 to 4 screens on Android

How many screens can spare Android devices cover well?

About four screens is the honest ceiling for spare Android devices. Each one needs its own app install, playlist push, storage space and power schedule, and at four screens you can still service every device in a single afternoon.

Three to four screens in one building is where reuse earns its keep. The software is free, so what you spend is attention: one install per device, one server address typed into each app, one power schedule per screen. That is an afternoon of setup and a few minutes a month.

Past four or five screens the arithmetic turns. Every added device brings another app to update, another box to walk to when an update crashes it or storage fills up, and another schedule to keep straight. Bought players or displays then cost less than your hours. The turn arrives sooner if the screens sit in several buildings, because each change becomes a trip or a remote session per site; self-hosted signage across multiple locations is the next question up, and it needs design choices this article skips.

Which requirement on my list decides the software?

Date and time, local video files and a YouTube item are the easy three of the four requirements; the login page is the one that picks the software for you.

Date and time eliminates nothing: every player in this space has a clock slide or widget.

Video files come down to the codec, not the app. Encode as H.264 MP4 at 1920 x 1080 and any Android box of the last decade decodes it in hardware. A clip that stutters in one app usually plays fine after a re-encode, so fix the file before blaming the device.

YouTube is a trap in this category. A YouTube page shown inside a player's browser view generally refuses to autoplay, which is how embedded browsers behave; the article on embedded webpage video in signage players explains why. Plan on MP4 files you have the rights to, and test any app's YouTube promise on your own page before you standardize on it.

Which free self-hosted route fits which screen?

Pick the route by what each screen must show, because a free self-hosted CMS, a single-device app, a browser in kiosk mode and a bought player each cover a different slice of the job.

The word free hides a split worth checking. Some self-hosted projects give away the server and sell the Android player app, and some trials stop accepting playlist changes after 14 days, which leaves screens frozen with old content. Read the license of the player app before you standardize, not just the license of the server.

Prefer an app that keeps a local copy of its schedule as well. A server that reboots at 2 a.m. should not disturb the screens.

Why do most Android players fail on a login page?

Most embedded signage players open a protected page only when the site speaks Basic access authentication, the scheme where the browser sends a base64 username and password with every request and which you can often write straight into the URL.

Basic auth is the old, simple scheme: the server asks for credentials, the browser answers on every request, and because there is no form and no session to keep alive, a player app can join in by accepting the credentials in the URL, in the form https://username:password@host/dashboard. On a page behind Basic auth, most of this article's problem disappears.

A form login is a different animal: it needs cookies, redirects and usually JavaScript, and a signage player's browser view is a stripped-down place. Single sign-on is harder still, because identity providers commonly treat embedded browser views as unsafe and block their sign-in flows there. Players hit the same wall on pages behind that kind of login. Wiring single sign-on into a web view exists only as a development task inside the app itself, documented for app makers, not for signage installers. A player that has not shipped that flow will not sign you in, however long you configure it.

What a player shows a web page in is a browser view with limits of its own; what to know about a web page signage player collects what to expect from the approach.

How do I put a login into the URL a player opens?

Ask whoever runs the site for a read-only account for the screen, then test the page at a URL built as https:// followed by the username, a colon, the password, an @ sign and the page address, over https so the credentials travel encrypted.

Three moves, in order:

1. Ask for a dedicated account, not your own login: an account named for the screen, with read access to the page and nothing else, because the password is about to live on a device anyone in the building can reach.
2. Put the credentials into the URL and load it on the device. If the page appears full screen, the requirement is met; add the URL as an item in the app's schedule so it shows on a timer.
3. Scale the page with the app's zoom or page-scale setting. Apps that show pages usually carry one in their display settings, and it is how a dashboard built for a desktop monitor fills a 1920 x 1080 panel.

If the site cannot speak Basic auth, do not bend the player around it. Ask IT to publish a second, read-only view of the page behind Basic auth, or front the site with a small reverse proxy that adds the header for internal addresses. A proxy brings failure modes of its own, which the article on signage CMS media downloads failing behind a reverse proxy lists.

One security note, and it is the one that matters here: treat that password as public. It sits in the player's settings and in the CMS entry, so give the account read-only rights to the one page and keep the whole thing on https.

Why do short video clips flash black between files?

Clips of 1 to 2 minutes that blink to black at every change are a per-file symptom, and a 30-minute test with your shortest clip on repeat tells you which kind of problem you have.

Queue the same 1-minute clip ten times. If the blink lands only at the joins, the player is reopening the video for each file; several apps offer a choice of video decoder in their settings, and switching it removes the blink. If the picture also breaks up inside a clip, the box is out of decode headroom: drop the file to 1280 x 720 or a lower bitrate and test again.

The design fix works on every player: stop cycling short clips as separate files. Join them into one reel, so 8 clips of 2 minutes become a single 16-minute MP4 (8 x 2 = 16), and the blink happens once every 16 minutes instead of once every 2. A still slide between the clips does the same job by making each change deliberate.

Freezes are the second symptom worth a test before a box goes on a wall. Leave the playlist running through an 8-hour overnight soak on the exact device you plan to mount. An Android TV box with 1 to 2 GB of memory is the usual weak point; the article on Android TV for digital signage covers what those boxes do well and where they stall.

What does a 4-screen example look like end to end?

Four screens, four spare Android boxes and one login page resolve like this: three screens play free self-hosted content on hardware already in the building, and the fourth turns on whether IT can publish the dashboard with Basic auth.

The building: an office with four TVs already on the walls, one in the lobby, one in the corridor, one in the staff room and one beside the meeting room door, that one meant to show the room-booking dashboard. In a drawer: four Android TV boxes left over from a meeting-room upgrade.

Lobby and corridor: the free self-hosted CMS with its app on two boxes. Content is a date-and-time slide plus the promo clips joined into one reel: 8 clips of 2 minutes become a single 16-minute file (8 x 2 = 16), so the box opens the video once per loop and the blink lands once every 16 minutes.

Staff room: the third box, same show with a notices slide added. Nothing about it differs, which is the point of standardizing three file-based screens on one app.

Meeting-room door: the fourth box, pointed at the dashboard. The test comes first: a 30-minute session with IT to publish a read-only booking view behind Basic auth, at a credentials-in-URL address, scaled to the panel with the app's page zoom setting. If IT agrees, four screens run on hardware the building already owns. If the dashboard is locked to single sign-on and IT cannot re-publish it, the three file-based screens stay reused and this fourth screen moves to a small x86 panel PC running a real browser in kiosk mode, which holds a login session a signage web view cannot.

The time budget, added up: 30 minutes per box to install the app, enter the server address and push the playlist, so 4 x 30 = 120 minutes; 30 minutes with IT for the login test; 150 minutes hands-on, or 2.5 hours, plus one unattended 8-hour soak overnight.

When should I stop reusing spares and buy players?

Recommendation: Reuse spare Android devices for up to 4 screens in one building while every page they show speaks Basic auth or needs no login, and move any screen past that point, or any screen behind a form login, to bought hardware.

The decision, case by case:

• 1 to 4 screens, one building, pages that need no login or accept Basic auth: reuse the devices, self-host the server, and put one app on every screen so they all behave alike.
• A form-login or single sign-on page that IT cannot re-publish: give that one screen a real browser in kiosk mode or a small x86 panel PC, and keep the rest reused. Do not bend a working three-screen setup around one page.
• 5 or more screens, or screens spread over several sites: stop counting on spares. Bought players or all-in-one displays beat the per-device maintenance, and the design questions change scale.
• A screen that only ever shows files from a card: a panel-mount display with the player built in removes the spare box, its power lead and its HDMI cable from the job entirely.
• A screen that hangs in a lift: different rules apply before anyone mounts hardware there, and the elevator screens guide lists what to settle first.

Before you commit, get written answers on four points from any app you shortlist:

• The minimum Android version and the license of the player app itself, because a free server with a paid app is a common split and the trial behavior lives in the app.
• Which login methods the web page item supports. Basic auth written into the URL is the one to count on; anything beyond it, test on your page.
• Whether the app keeps a local copy of the playlist, so the screens play through a server reboot.
• Whether the player offers a choice of video decoder, which is the fix for blinks between clips.

Questions