Setup Switcher Addon

Suggestions
1

Hi, would it be possible for there to be a method of using an add-on for setups, similar to the Scheduled Player date/time picker, but one that can be used to automatically change switch the setup that a device uses at preset times and used as an add-on?

If this add-on could then be added to the HD Image/Video Player setup it would be really useful, as it would allow the current setup to be switched between various setups at pre-determined times.

Similar to the Scheduled Player setup, but where you can also select from a dropdown of available devices that you would like the setup to be switched to at preset dates/times/.

2

This sure would be useful but it’s a massive change and not something that can be added trivially:

Right now individual setups are what’s assigned to a device. A setup includes one or more packages, all assigned assets as well as its configuration. The result is a list of files needed on the device (if you have ssh access, have a look at /space/cache/sync.data!). When a setup is assigned to a device, this list is transferred to the device which will then fetch any missing files. Once all files are locally available, the device switches to these collection of files and plays them. Nothing changes on the device after that, unless a new setup is assigned. All scheduling logic is purely within the downloaded package code and the device doesn’t have to know how any of that works.

What you suggest might be solved by not having a single setup assign to a device, but instead a “setup schedule”, composed to multiple setups and scheduling information on when each setup should be active. While this sounds like a simple change, it’s rather massive:

  • The relationship between device ↔ setup would have to be replaced by device ↔ ‘setup schedule’ ↔ setup.
    • This would require incompatible API changes and add a completely new “object” type.
    • The device would need a locally running scheduler that switch between one of the assigned setups
  • As the scheduling code is now baked into the OS, changes to the scheduling become harder to implement. Right now, a package can instantly implement some new wild scheduling logic and you can immediately assign it to any running device. No OS upgrade needed, as the logic happens purely in code that isn’t part of the OS, but part of the assigned setup.

The alternative would be to have a backend-side “automation engine” running that modifies assigned setups based on a schedule. Essentially, automating the click on “Assign setup to device”. This isn’t possible at the moment using a visual interface. But customers already do this on their own using the update device API call, by setting a new setup_id. This works pretty well, but has a downside: It only works, if the device is reachable. Otherwise a changed setup only becomes active on a device once the device is back online.

The scheduled player package is an attempt at avoiding all this added complexity. Instead of adding any of the above, the scheduled player package includes its own scheduling system. It runs purely in code that can be trivially updated on a device. I guess my main question would be: What’s missing in the scheduled player for your use case?

3

OK, yeah it sounds complicated! :slight_smile:

This request is related to my post about recreating a McDonalds style menu display.

As it’s possible to create a video wall display effect by using the HD Image/Video setup and using the ‘Synced Playback’ option which, as long as all video files are exactly the same duration, could be used to create a menu display that consists of five setups, and five devices to create a five screen video wall, it would be ideal if it were possible to change the setups at preset times to be relevant at different times of the day/week.

I guess what I want is a mix of the Schedule Player and the HD Image/Video player setups, so it would be possible to create a video wall of synced content across multiple screen, but then also schedule the contents to change when needed.

So either adding scheduled playlists to the HD Image/Video setup, or adding the Synced Playback option to the Scheduled Player setup would mean that it’s possible to switch the contents of a video wall according to a schedule.

I know it’s not as simple as that though!

4

I can already achieve the desired result using a Pi4 and the Scheduled Player setup, as it’s possible to span the output across two screens, so if there was a way to do the same but synced across multiple devices that would be awesome.

5

I haven’t tried, but would multiple Scheduled Player Setups play in sync, if all content was set to the same duration, time zones, and schedules?

Would the devices switch at exactly the same time if on the same network, to allow for multiple parts of a video to play back as a single video spread across multiple screens and stay in time?

6

In that case, it might be worth looking into the scheduled player package to see how complicated a synced playback option would be. The main reason this doesn’t exist at the moment is because of how synced playback works in all packages that support it. Basically all devices look at the current time, the playlist duration and they all can independently decide what to show without any communication between them. (See also this post). Now imagine the following schedule in the scheduled player package:

  • Show playlist1 [image1 for 30 seconds, image2 for 30 seconds] at all times
  • Show playlist2 [image3 for 10 seconds, image4 for 15 seconds] between 2pm and 3pm

This essentially results in:

  • Before 2pm: A combined playlist of 30+30=60 seconds total
  • Between 2 and 3pm: A combined playlist of 30+30+10+15 = 85 seconds total
  • After 3pm: A combined playlist of 60 seconds again.

Now imagine you turn on your devices at 1pm. They look at the scheduling info and decide to play the 60 second playlist. Now due to how synchronization works at the moment, they decide to show image1 at each full minute, so 1:00:00, 1:01:00, 1:02:00 and so on and image2 at 1:00:30, 1:01:30, 1:02:30 and so on. Each device can easily calculate these offsets independently and arrive at the same timestamps to switch between those two images. Easy enough and the playback is synced.

They do this for an hour until it’s 2pm. At precisely 2:00:00, image2 has been playing for the configured 30 seconds just as the new 85 seconds long playlist becomes active. Now the system can do its calculation again: image1 starts at 2:00:00, image2 starts at 2:00:30, image3 starts at 2:01:00, image4 starts at 2:01:10 and the cycle restarts with image1 starting again at 2:01:25. Repeat the calculation until 3pm.

But now we have a problem: One hour (2pm to 3pm) consists of 3600 seconds. The playlist during that time is 85 seconds long. If we calculate how often we can repeat the playlist during that hour we arrive at 3600s/85s = 42.352941 cycles. Ugh. That’s not an integer. In other words: The 85 seconds playlist doesn’t fit into the 3600s slot between 2pm and 3pm. So now we have to decide what to do at 3pm. One option would be to let the 85 second playlist finish playing its 43th cycle and only then switch back to the 60 second playlist. This would then happen at 3:00:55 (2:00:00 + 85s * 43) . So now we suddenly have a 55s second offset we have to carry around.

Or we could forcefully interrupt the 85 second playlist and switch back to the 60 second playlist at 3:00:00.

The latter is more predictable as otherwise we run into the additional problem of what happens when a device gets started at 3:15 for example. Instead of looking at the currently running playlist alone, it would also have to look back in time to see how much offset was accumulated in the past. The downside is of course that current content would be forcefully interrupted at each schedule change.

And of course that was a rather simple example. You can have more complex schedules that result in more frequent schedule changes. Or the user could modify the currently running setup by adding or removing content or changing the schedule. At that point, forcefully interrupting content to switch to the next one will probably be more noticeable.

I’ll think about this a bit more to see how this could be implemented in a way that’s both easy to understand and doesn’t result in too much scheduling complexity.

7

Thanks for the in-depth explanation, it certainly isn’t simple!

As you mentioned, forcing the playlist to change would be easier, and if it meant that it was possible to achieve a scheduled video wall, a ‘jump’ between playlists would be acceptable to most I would think.
We have had a similar predicament when using Scheduled playlists with video content that is of a longer duration, and that isn’t possible to change at the end of the content, as it would cause the playlist to ‘overrun’ into the next schedule.

From what I can remember, what we do in those scenarios, is have a a playlist set as a fallback playlist, between two times when we need a playlist to be forcefully changed at a scheduled time.

So if we need a playlist to start exactly at midday, we would run a playlist up to say 11:45am, and then have a playlist set as fallback, with the next playlist not due to start until midday.

From what I can remember, this means that the playlist scheduled at midday will start at midday, even if the fallback content is halfway through playing a video file.