Screen is online but MagicINFO shows "Disconnected"
MagicINFO decides "connected" from a timestamp that only the display's periodic check-in (roughly every ten minutes) refreshes, not from its five-second polling. A screen that polls perfectly can therefore still show as disconnected when that check-in stops updating the timestamp.
Symptoms
- The screen plays its content and may even accept commands, but the device list shows it as disconnected or powered off.
- The status flips between connected and disconnected during the day.
- The dashboard's connected count is lower than the number of screens you can see working.
How MagicINFO works out "connected"
A device counts as connected while its last connection time is newer than (monitoring interval + 1) minutes. The monitoring interval is a per-device setting with a default of 10, so the window is 11 minutes.
A display talks to the server in several ways, and only some of them refresh that timestamp:
| Traffic | How often | Refreshes "last connection"? |
|---|---|---|
Command poll (GET /MagicInfo/WSRMReverse?DEV_SN=<MAC>) | every 5 seconds | No |
Status upload (same address, POST) | every 60 seconds | No |
| Registration exchange and its follow-up step | about every 10 minutes | Yes, when the follow-up step completes |
So "disconnected" really means "no completed check-in for 11 minutes", whatever the polling looks like.
Causes we have found
- Real gaps. The network drops out, or the screen is switched off at the mains. A screen in standby normally keeps polling.
- URL Launcher screens (seen on 21.1070). When a display's current source is URL Launcher, the server leaves the follow-up step early and never refreshes the timestamp. These screens drift in and out of "disconnected" although they poll every five seconds.
- Displays with a limited built-in client, for example some outdoor models such as the OH55A-S. They do not send the full follow-up information, so the follow-up never runs. The registration step stores its own time but not the last connection time, so the field can stay empty and the screen shows as permanently disconnected. You can spot these displays because their firmware and series fields stay empty, and their application version does not mention
com.samsung.ep.wsrm-service.
Fix
- Prove the screen is talking. If your server keeps a Tomcat access log, look for
WSRMReverse?DEV_SN=aa-bb-cc-dd-ee-ff(the display's MAC address, written with dashes) about every five seconds. Gaps mean a real network or power problem, so work through Display not registering with the server instead. - Read the timestamp. If you have read-only database access, compare the device's
last_connection_timewith the current time. A value that stops advancing while polling continues points to cause 2 or 3. - Check the source and model. Is the display in URL Launcher mode? Does its application version name the full client? That tells you which cause applies.
- Check the application log (
runtime\logs\wsrm.login the installation folder) around the display's check-ins for errors from the follow-up step. - Causes 2 and 3 are server-side. They are issues in the server application of some MagicINFO builds (we saw them on 21.1070; other builds may behave differently), not faults in the display or the network. Check whether a newer MagicINFO Server build or patch is available for your installation. If a hosting provider runs your server, ask them about it.
- Do not paper over it with a script. It is tempting to have a job push the timestamp forward for screens that are polling. We ran one for a while, and when its input went stale it kept a screen that had really gone dark looking online for 38 hours. A wrong "connected" is worse than a wrong "disconnected".
How to confirm it worked
Watch the device for at least 30 minutes, which covers several check-in cycles. The last connection time should move forward about every ten minutes, and the status should stay connected without flipping. For URL Launcher screens, confirm across a normal working day.
Related
- Display not registering with the server
- MagicINFO ports explained: 7001, 7002, 443
- Schedule plays at the wrong time
- Manual: Device information
- Manual: Viewing device health
Checked against MagicINFO Server 21.1070 behaviour, October 2026.
Prefer not to run the server yourself? MiCloud hosts MagicINFO for you.