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.