Player updates
A release is unavailable
Section titled “A release is unavailable”A Player release must be published, verified, and cached before Studio can deploy it.
Open Settings > Player updates, check the expected release files, and review any verification error.
GitHub synchronization can stop when the API rate limit is reached. If that happens, connect the configured GitHub account or use the supported GitHub token configuration for your deployment.
Platform-specific install problems
Section titled “Platform-specific install problems”Android or Fire OS may require local permission to install apps or may show a confirmation prompt for an update.
Studio shows whether the TV has the install permission on its Reliability tab. Even with it, the device firmware can still require someone at the screen.
If Android reports a signing-certificate mismatch, the installed Player and the new release were signed with different keys. Android cannot install one as an update over the other. Use the production-signed Player and keep the same production signing key for future releases.
The AppImage update flow is for Tilecast’s managed AppImage installation.
Current Tilecast Linux installs use systemd user services, so manage them with systemctl --user, not the system service manager.
If an older Player uses a custom service or obsolete AppImage startup method, move it to the current Linux setup before expecting Studio-driven updates to work.
If a screen is listed as incompatible, the release was built for another architecture. Upload the release for the screen’s architecture (x86_64 or aarch64).
If a screen shows Failed, it didn’t keep the new release and runs its previous one. Common reasons:
- the screen didn’t have enough free disk space to download or install the release;
- the new release didn’t start or kept restarting, so the screen returned to its previous release;
- the screen restarted or lost power before the update confirmed. This always returns to the previous release, even if the new one looked healthy;
- the screen couldn’t reconnect or show content before the confirmation deadline.
To see what happened on the screen, run sudo /opt/tilecast-edge/current/bin/tilecast-edge-update status.
Update Tilecast Edge explains each rollback reason.
If the screen shows its recovery screen after a rollback, the new release changed the local state database to a version the previous release can’t read. Studio can’t fix this; see Recover after a rollback.
If there is no Windows release in Studio, open Settings > Player updates, choose Windows, and select Sync from GitHub. Stable releases always include a signed Windows package.
If the MSIX installation fails:
- Untrusted publisher: Windows must trust the MSIX signing certificate. Do not bypass package signature checks. For a self-signed or organization-issued certificate, have your administrator verify its source and import its public
.cercertificate into the local computer’s Trusted People store. See Publisher certificate trust. - Wrong architecture: Download
x86_64for a Windows x64 PC oraarch64for an ARM64 PC. Check Settings > System > About and use the matching package and update manifest. - Wrong package identity or signing certificate: Install a release from the same Windows publisher and package family. Don’t work around an identity mismatch by deleting a paired Player; inspect the package and release first.
- WebView2 is missing: Install Microsoft’s WebView2 Evergreen Runtime, using the Standalone installer on an offline PC.
- Player does not return after a reboot: Confirm that Windows signs in to the signage user’s desktop and that Tilecast Player is enabled in Startup apps. The MSIX starts at user logon, not at the Windows sign-in screen.
If the deployment is waiting to complete, check that the Player restarted into the expected version and reconnected to its paired server. For MSIX installation and certificate failures, see Microsoft’s MSIX troubleshooting guide.
A canary deployment paused
Section titled “A canary deployment paused”A canary deployment waits for the selected canary screens to finish updating and reconnect.
If one fails, enters safe mode, or never reconnects, Tilecast can pause the rest of the deployment.
Check the failed screen before pushing the same release to the rest of the fleet.
See Update Tilecast Player for the deployment workflow.