# Player updates

## 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

Android or Fire OS may require local permission to install apps or may show a confirmation prompt for an update.

Commissioning checks the install permission, but 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 stable Linux 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](../../edge/updates/#when-edge-rolls-back) 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](../../edge/updates/#recover-after-a-rollback-to-an-older-state-database).

## 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](../../administration/player-updates/) for the deployment workflow.