Android signage player keeps losing CMS connection

The status page sorts the causes first

Tap the screen while the player app is running and choose Status from the action bar at the top. The page prints what you need: whether the app is connected and logged in, the last time it reached the CMS, and the Android version the box runs. Read it against this list.

• Says connected, and the screen plays your scheduled content: nothing to fix, move on.
• Says connected, but the screen plays the standard layout instead of your scheduled content: the link is healthy and the schedule is the problem.
• Says connected, but the last connected time is hours behind the wall clock: the link drops between syncs and only looks alive right now.
• Says not connected, but the box's browser opens the CMS login page at the same address: the server is reachable and the address is right, so the app's own connection is what fails.
• Says not connected, and the browser cannot open the CMS either: the server is unreachable. Wrong address, server stopped, or a port blocked on the path.

The second and third rows look identical from across the room, which is why the status page comes before any cable or setting.

Connected with the standard layout: fix the schedule

A connected player with nothing scheduled falls back to the standard layout it ships with, and if no default layout is assigned to the display, your campaigns never appear no matter how healthy the link is. In the CMS, assign a default layout to that display, then check the campaign itself: scheduled to this display, dates covering today, and holding the content you expect. No network setting changes in this case. The whole fix happens in the CMS in a few minutes.

The 8080 test finds a filtered port 80

Change the web server's listen port from 80 to 8080, put the port in the player's address so it reads http://192.0.2.10:8080, and let the app connect once. When it connects at once and pulls the layout straight away, the old port was the problem: something on the path, a router rule or a guest Wi-Fi filter, was interfering with port 80 traffic.

Close it one of two ways. Keep the CMS on 8080 and put :8080 in every player's address; 8080 is the conventional alternate HTTP port, so leaving the server there costs nothing. Or find the rule blocking port 80 and allow the CMS through it. A reverse proxy in front of the CMS can filter traffic the same way; the article on media downloads failing behind a reverse proxy covers that variant.

Never connects while the browser connects: TLS and the clock

Open the CMS address in the box's own browser. If the login page loads, the server is reachable and the address is right, and a player that still will not connect is failing at its own handshake. Now read the Android version on the status page.

A server configured for modern TLS only rejects devices earlier than Android 4.4.2 at the handshake, and some Android 5 and 6 firmwares fail the same way. Mozilla's Server Side TLS guidelines publish ready-made server configurations for exactly this situation. The intermediate compatibility set, which includes the older protocols those devices need, is the guidelines' default recommendation, and an older compatibility set exists for the worst cases. Serve intermediate first. Move to the older set only for a device that still refuses to connect, and only on a server your players alone reach, because that set trades encryption strength for reach.

One more handshake killer sits outside TLS: a box whose date, time or timezone is wrong fails certificate validation on any Android version, because certificates carry validity dates. Set the clock against a phone or watch and connect again.

The checks, in order

1. Open the status page: tap the screen while the app runs, choose Status from the action bar. Note the connection state, the last connected time and the Android version.
2. Compare last connected with the wall clock. Hours behind means the link drops between syncs even while the page says connected.
3. Check the CMS address character for character: the server address, the port, and no folder suffix unless the CMS really lives in one.
4. Open the same address in the box's browser. That separates server reachability from the app's own connection.
5. Run the 8080 test if the link falls: server port 80 to 8080, address updated, one connect attempt.
6. Check the box's date, time and timezone.
7. Read the Android version. Earlier than 4.4.2 means the CMS server should serve Mozilla's intermediate compatibility TLS set.
8. Run a network point to the player and wire it where possible. Crowded venue Wi-Fi is the one cause on this list with no setting to change, and a cable removes it.

Whether that on-premise CMS server needs an internet path of its own is a separate question; the article on on-premise signage CMS internet requirements answers it.

What a connection drop should cost you

After one good sync, downloaded media sits on the box, so a short drop should not blank the screen; the show keeps playing from the local copy. If your screen goes dark the moment the link falls, the app never completed a download, and the connection fix comes before any content work. The article on where an Android signage player stores downloaded media shows where to confirm a download actually landed.

Our own player runs the same rule with no CMS at all: it plays images and MP4 from microSD or USB, keeps a copy in internal memory, and if the app stops it is designed to start again within seconds and go back to playing. If your show is images and clips, you can retire the CMS from that screen entirely; the signage player category is the place to start.

Example: one screen, three findings, one port change

A bar hangs one Android box on the venue Wi-Fi, with the CMS on a small server in the office at 192.0.2.10. The screen shows the standard layout while the schedule says a campaign should be running. The status page reads: connected, logged in, last connected 09:27; the wall clock says 23:40.

Finding 1: connected plus the standard layout is a schedule fault. The display has no default layout assigned. Assigning one gives the screen something to show, but the campaign still has not arrived.

Finding 2: last connected 09:27 against 23:40 is 14 h 13 min without a successful sync. The campaign went live at 18:00, so the screen played 5 h 40 min past the change without picking it up. The link is dropping silently. The address reads http://192.0.2.10/cms/ with the CMS at the web root, so the folder suffix goes; the link still falls.

Finding 3: the 8080 test. The server's listen port moves from 80 to 8080, the address becomes http://192.0.2.10:8080, and the player connects at once and pulls the campaign straight away. Port 80 was being filtered on the venue router.

Decision: the CMS stays on 8080 permanently and every player address carries :8080. The status page now shows last connected moving each time the app syncs, and the campaign plays. Total work: one port number in the server configuration, one in each address, one default layout.

The decision

Recommendation: open the status page before you change anything. If it says connected and the screen plays the standard layout, fix the schedule in the CMS: assign a default layout and check the campaign dates, and leave the network alone. If the last connected time is hours behind the clock, run the 8080 test; when 8080 holds where 80 failed, keep the server on 8080 with :8080 in every player address, or clear the rule that filters port 80. If the app never connects while the box's browser opens the CMS, check the Android version and serve Mozilla's intermediate compatibility TLS set from the server on anything earlier than 4.4.2. Run a cable to the player wherever a network point exists.

With the link holding and the campaign playing, the next complaint in a bar or a shop is usually text too small to read from the counter, which the guide on screen size and viewing distance covers.

Questions