Have more questions? Submit a request

🛟 Troubleshooting guide

  1. signageOS
  2. Support and Helpdesk
  3. Troubleshooting

Pre-Provisioning Checklist

Before you start the deployment or takeover of devices, ensure the following requirements are met.

Network requirements and settings

To avoid issues later, we strongly recommend checking the availability of all required domains by network ping.

Device compatibility and firmware updates

  • Check the FW Requirements guide to be familiar with this topic.
  • Always ensure devices are running on the supported FW or newer; FW requirements are listed for each device on the Supported devices page.

Provisioning Process

Always follow the Step-by-step guide to provisioning devices with troubleshooting tips for common issues. For each device, here are the common pitfalls:

Date and time settings

Misconfiguration of date and time is causing 90% of provisioning issues. Always triple-check that both - date and time - are configured correctly. 

If you are using an NTP server, make sure it's available and reliable on the device's network. The most reliable NTP servers are:

  1. time.google.com
  2. time.apple.com
  3. time.windows.com

If you can, limit the use of pool.ntp.org as it's slow and can cause issues on some devices (typically Tizen devices).

Network availability

While deploying devices to customers' sites, it is very often the network is misconfigured. Checking available domains and ports can be done using signageOS OSD. Open the OSD and check the Network tab.

Service availability

In case the device is not being provisioned or is not showing a Verification hash, you can check the signageOS status page: https://status.signageos.io for any incident or reported service degradation.

Typical issues per device type

Samsung

  • If you see "Unable to connect" during installation, triple-check that the URL in the URL Launcher/Custom app menu is typed correctly (e.g.: http:// instead of https://, sigangeos instead of signageos, tizen.signagekiosk instead of tizen.signageoskiosk)
  • If the URL is correct, then check the device time and date

LG

  • If you see "Unable to install" during installation, triple-check the URL in the SI menu and validate the time and date on the display

How to verify successful provisioning

The device is successfully provisioned once you confirm the following:

  1. Device is visible in the Box
  2. Device reports pings and is visible as an Online
  3. Device sends screenshots that are visible in the Box
  4. [Optional] Device receives Applet from signageOS (not applicable to CloudControl-only deployments)
  5. Android device - the device is locked to Kiosk mode; this step is highly recommended for all other devices as well, but it's specifically crucial for Android devices
  6. Device has set scheduled daily reboots or native timers, ideally deployed as a part of device policy
  7. Device has disabled both Native and Remote debugs

Operational Troubleshooting

Network

If you are experiencing any of these issues:

  • Observing inconsistent connectivity
  • Device in Pending state
  • Multiple (> 4) connections in the Connections table
  • Intermittent responsivity for device actions

Most of the time the issue is related to the network. Please check that the network is configured correctly and is stable. Check Wi-Fi AP signal strength and conflicting Wi-Fi networks. If you are using a proxy, validate TTL on the tunneling. Ensure all ports and domains are allowed for the specific ethernet port. Check that there is no additional/new configuration of firewall rules done by the network teams of your customer.

Date and Time

If you are experiencing any of these issues:

  • Device is not playing content based on a set schedule
  • Device is not starting/shutting down according to Timers
  • Device is reporting "Unable to establish a secure connection"

In such cases, the root cause of these issues is incorrect time and date. Check the date and time on the device. Check the availability of the NTP server in the device's network. Force a timezone update on the device and perform the reboot.

Samsung MagicInfo / RM server

In case you are running a Samsung MagicInfo/RM server along with signageOS:

  • Ensure that devices have the correct timezone set and that the timezone in the RM server matches the timezone in signageOS
  • If you are not using NTP and the customer has Tizen devices in VPN, these devices will get time-based on the VPN server location

SSL certificates

If you see devices offline or your Applet is not communicating with your server, there is a chance SSL root certificates are expired. This issue can occur in the following scenarios:

  • Device has incorrect time and date -> please see the previous section
  • Device is trying to communicate over SSL with a certificate that expired or is not supported on the device

Typically we see issues with the latest Let's Encrypt certificates that are using root certificates that are not available on older (legacy) devices. We recommend using the GlobalSign certificate that has full coverage across all devices:

"Black screen" Applet-specific Troubleshooting

Below are known troubles that you can face while running your Applet in production and that might cause playback disruptions:

CORS

Downloading files using JS SDK requires your server to comply with CORS. You can check the ORIGIN headers for each platform here: https://docs.signageos.io/hc/en-us/articles/4405231882002-Network-Firewall-ports-and-domains#http-s-requests-origins-going-from-applet

Troubleshooting:

  1. Open Postman
  2. Create a GET request & insert your file URL
  3. Press Send
  4. Check the Response Headers regarding request origin
    1. The easiest fix is to use *, or strictly define allowed origins based on the link above

iFrame origin

Similar to CORS and request origin, iframe origin restriction can block live web content from loading. iFrames are served from device storage and their origin differs based on platform. You can check the ORIGIN headers for each platform here: https://docs.signageos.io/hc/en-us/articles/4405231882002-Network-Firewall-ports-and-domains#http-s-requests-origins-going-from-applet

 

Pre-flight CORS requests

If a request to an external API mandates a CORS header response (POST, PUT, DELETE), a pre-flight request is made automatically by the browser as part of the CORS standard. Make sure that the OPTIONS call does not require any special headers (x-API-key, authentication, etc..). These are not passed from the original request, and as a result, you will get a CORS error.

More info here: https://developer.mozilla.org/en-US/docs/Glossary/Preflight_request

HEAD requests

CoreApps are calling HEAD requests on files to check their file size. This mechanism is used to avoid downloading files that are too large to fit into the remaining storage. Some file/blob storage services (e.g.: AWS S3, Azure Blob) do not allow HEAD requests by default. It's recommended to enable them.

Heads up: specifically for those that are using SMIL Player, you have to enable the HEAD requests or adjust your SMIL playlists.

 

Was this article helpful?
0 out of 0 found this helpful
Share