Scheduling a playlist used to mean filling in a condition builder and then trusting that the result said what you meant. If a playlist had three rules, working out when it actually played took some reading.
The Schedule tab (Playlists > a playlist > Schedule) now lists each rule as a line of plain text, naming the dates it covers, the days of the week it runs on, and the hours it plays, instead of a form you have to read back to yourself. Above the list, an Effective schedule block states when the playlist plays once every rule is taken together. A playlist with no rules says so directly: “Always active. This playlist plays on every screen, every day, all day.”
Editing a rule opens a dialog split into Dates, Time of day, and Days of week, so you work on one part of the schedule at a time and watch the sentence update as you go.
Rules that will not do what you meant say so
A schedule can be self-contradictory in ways that are invisible until nothing plays. Each rule now carries its own status:
- Never plays, for a rule whose conditions cannot all be true at once, such as a date range that contains none of the weekdays it allows
- Expired, for a rule whose end date has passed
- Pending, for a rule that has not started yet
Dates can have exceptions
A rule can now exclude individual days inside its own range, which is the difference between a QSR menu board that runs every day of the year and one that runs every day except December 25. Excluded dates show as removable labels under the date range, so a closure that moves is one label to swap rather than a schedule to rebuild.
Schedules built through the API
A schedule created through the API that the editor cannot represent stays read-only, as before, and now says which of the two reasons applies: it cannot be shown as rules at all, or it is too complex to show as rules. Either way it keeps working exactly as it did, and it can still be changed through the API.