Skip to content

Playback and schedules

Start with the screen detail page and Activity. Compare what Tilecast selected with what the Player says it is playing.

Temporary content can take priority over the normal screen assignment. The order is:

  1. active Takeover;
  2. on the AppImage Player, active AirPlay;
  3. Quick Present;
  4. the highest-priority active Schedule;
  5. the normal screen or Display Group assignment.

When the temporary content ends, Tilecast checks the current schedule and normal assignment again.

Check that the screen has an assignment and that the items inside it are available to play.

A connected Player may keep showing the last working presentation if a newer one cannot be prepared. Media that is not Ready, expired content, an unavailable Website, a missing Player feature, or an incompatible Layout can stop some or all of the new presentation from becoming active.

On Android, an ordinary playlist continues with the entries the Player can render and skips unsupported entries. A synchronized Display Group keeps its shared timeline, so one unsupported entry can keep the group from playing. Check each Player’s capabilities and the content assigned to every group member.

Use the Dependency Graph when you need to trace the assets and Data Sources used by a presentation.

A black screen on an Android TV, Google TV, or Fire TV Player can have three different causes. Check Player health on the screen’s Overview first.

  • Renderer disconnected or Renderer unavailable. The display engine isn’t running. Look at Last renderer failure. On the TV, the Player shows Display unavailable with a reason code and a Restart display button, instead of a plain black screen. Select it. If it keeps failing, check that Android System WebView is up to date, then restart Tilecast.
  • Waiting for playback. The display engine is running and the content hasn’t started yet. Check Activity for the item that’s loading.
  • Healthy. The content is probably black. Check the item in the Media library or Layout preview.

A black screen that lasts more than a few seconds and doesn’t show Display unavailable is a bug. Report it with the Player version, the Android System WebView version, and the output of adb logcat -d -s TilecastRenderer. See Android development for the log events.

Changing a screen’s default content doesn’t update the TV

Section titled “Changing a screen’s default content doesn’t update the TV”

Studio sends the new content to the Player as soon as you save the assignment. The screen should change within a few seconds. If it doesn’t:

  1. Open the screen’s Overview and check Player health. The screen must be online with a healthy renderer. Fix a disconnected renderer first.
  2. Check Activity. If the new content failed to prepare, Studio shows the reason there, for example a Layout that holds a Playlist zone with a Widget in it.
  3. Check that no Takeover, Quick Present, or active Schedule has priority. They show before the normal assignment.

New content appeared briefly, then the old content came back

Section titled “New content appeared briefly, then the old content came back”

Tilecast Edge, Windows, and Android Players try new content on screen before they keep it. If the display engine refuses the new presentation, or nothing in it renders within 30 seconds, the Player goes back to the content that last worked. A single item that fails, such as a Website that can’t load, doesn’t count: the Player skips it and keeps trying the rest.

While the new content is held back, the screen’s Overview shows it as Out of date, and Playback › Diagnostics shows a synchronization error that starts with activation_trial_failed. The part after the colon says why:

  • renderer_refused: the display engine refused the presentation. Check the Player version and Last renderer failure.
  • no_content_evidence: nothing in the presentation rendered within 30 seconds. Check that its media is Ready and its Websites load from the screen’s network.
  • trial_interrupted: the Player stopped while it was trying the content, for example after a crash or a power loss.

You don’t need to resend anything. The Player tries the held content again after one minute, then after 5 minutes, 15 minutes, and every hour. Saving a change that produces new content starts over at once.

After you restore the server from a backup, screens move to the restored content on their own, even though its version number is lower than what they last played.

Check the Schedule’s timezone and any Player clock warning.

Tilecast corrects for Player clock drift when evaluating schedules, content availability windows, and temporary presentations.

Around daylight-saving changes, Tilecast follows the selected timezone’s calendar rules instead of assuming every day is exactly 24 hours.

If a Player went offline before receiving a new one-time Schedule, it cannot know about that Schedule until it reconnects. Recurring rules the Player already has can continue offline when their required content is cached.

Screen Events show the same item starting and ending over and over

Section titled “Screen Events show the same item starting and ending over and over”

Open Activity > Screen Events for the screen. If one item starts and completes several times a second, the Player is remounting it instead of showing it. The item flickers, and it uses the display’s processor for nothing.

Tilecast doesn’t list these as plays in Proof of Play: a play needs at least one second on screen. It keeps the raw events so you can find the screen.

Check these causes in order:

  1. The item’s duration. An item stored with a duration of 0 used to be read as “zero seconds” by some Players. Open the playlist, set a duration of at least one second, and publish it.
  2. The Player version. Update the Player. Current versions read a missing or zero duration as “use the default”, never show an item for less than one second, and don’t restart an item that is already on screen.
  3. Synchronized groups. A group member with a zero-length slot affects every screen in the group. Fix the item’s duration first.

Cached content belongs to a specific Tilecast installation and screen.

If the Player was moved to another installation, replaced, or re-paired in a way that changes its screen identity, old cached state may no longer apply.

Do not copy another screen’s cache or Player state directory as a recovery method.