Config for scheduling window.

configuration/sample-development.engine.ini

@@ -63,16 +63,27 @@ api_port=3333
 
 [scheduling]
 # How often should the calendar be fetched in seconds. This determines the time of the last changes applied, before a specific show aired
-fetching_frequency=60
+fetching_frequency=50
+# The scheduling window defines when the entries of each schedule are queued for play-out. The actual window (scheduling_window_start - scheduling_window_end)
+# should be higher then the `fetching_frequency` to allow proper queuing. Otherwise the fetch might never hit the scheduling window, because the scheduling
+# logic is attached to the fetching logic. 
+# 
+# Following operations are related to the scheduling window:
+# 
+#   - Deletion of schedules/timeslots: Those are only accepted until the **start** of the scheduling window
+#   - Update/Delete/Assignment of playlists and entries: Those are accepted until the **end** of the the scheduling window; existing queued entries are updated
+#   - Pro-active fallback handling: Within the window it is continousely evaluated if some fallback playlist should be applied. The queued items are updated accordingly
+#
+# After the end of the scheduling window the pre-rolling phase starts. It's recommended that the end of the windows is approximately 4x times
+# higher than the preroll_offset, to leave enough space for all 4 fallback scenarios to pre-roll (normal, show, timeslot and station).
+# Note, the values for windows is defined as a offset minus the actual start of the schedule in seconds.
+scheduling_window_start=120
+scheduling_window_end=60
+# Playlist ID which is used for station fallbacks. Only used if no station fallback ID is provided via Steering. "0" means it is disabled.
+scheduling_station_fallback_id=0
 # How many seconds before the actual schedule time the entry should be pre-rolled. Note to provide enough timeout for
 # contents which take longer to load (big files, bad connectivity to streams etc.)
 preroll_offset=15
-# Max seconds before an new/updated/removed schedule is accepted. Its important that this value
-# is considerable higher than the `preroll_offset` plus any additional time for pro-active fallback
-# handling, being able to avoid issues with concurrent changes or timings.
-scheduling_window_offset=60
-# Playlist ID which is used for station fallbacks. Only used if no station fallback ID is provided via Steering. "0" means it is disabled.
-scheduling_station_fallback_id=0
 
 # Sometimes it might take longer to get a stream connected. Here you can define a viable length.
 # But note, that this may affect the preroll time (see `preroll_offset`), hence affecting the 

configuration/sample-docker.engine.ini

@@ -64,15 +64,26 @@ api_port=3333
 [scheduling]
 # How often should the calendar be fetched in seconds. This determines the time of the last changes applied, before a specific show aired
 fetching_frequency=300
-# How many seconds before the actual schedule time the entry should be pre-rolled. Note to provide enough timeout for
-# contents which take longer to load (big files, bad connectivity to streams etc.)
-preroll_offset=15
-# Max seconds before an new/updated/removed schedule is accepted. Its important that this value
-# is considerable higher than the `preroll_offset` plus any additional time for pro-active fallback
-# handling, being able to avoid issues with concurrent changes or timings.
-scheduling_window_offset=180
+# The scheduling window defines when the entries of each schedule are queued for play-out. The actual window (scheduling_window_start - scheduling_window_end)
+# should be higher then the `fetching_frequency` to allow proper queuing. Otherwise the fetch might never hit the scheduling window, because the scheduling
+# logic is attached to the fetching logic. 
+# 
+# Following operations are related to the scheduling window:
+# 
+#   - Deletion of schedules/timeslots: Those are only accepted until the **start** of the scheduling window
+#   - Update/Delete/Assignment of playlists and entries: Those are accepted until the **end** of the the scheduling window; existing queued entries are updated
+#   - Pro-active fallback handling: Within the window it is continousely evaluated if some fallback playlist should be applied. The queued items are updated accordingly
+#
+# After the end of the scheduling window the pre-rolling phase starts. It's recommended that the end of the windows is approximately 4x times
+# higher than the preroll_offset, to leave enough space for all 4 fallback scenarios to pre-roll (normal, show, timeslot and station).
+# Note, the values for windows is defined as a offset minus the actual start of the schedule in seconds.
+scheduling_window_start=600
+scheduling_window_end=120
 # Playlist ID which is used for station fallbacks. Only used if no station fallback ID is provided via Steering. "0" means it is disabled.
 scheduling_station_fallback_id=0
+# How many seconds before the actual schedule time the entry should be pre-rolled. Note to provide enough timeout for
+# contents which take longer to load (big files, bad connectivity to streams etc.)
+preroll_offset=30
 
 # Sometimes it might take longer to get a stream connected. Here you can define a viable length.
 # But note, that this may affect the preroll time (see `preroll_offset`), hence affecting the 

configuration/sample-production.engine.ini

@@ -64,15 +64,26 @@ api_port=3333
 [scheduling]
 # How often should the calendar be fetched in seconds. This determines the time of the last changes applied, before a specific show aired
 fetching_frequency=300
-# How many seconds before the actual schedule time the entry should be pre-rolled. Note to provide enough timeout for
-# contents which take longer to load (big files, bad connectivity to streams etc.)
-preroll_offset=15
-# Max seconds before an new/updated/removed schedule is accepted. Its important that this value
-# is considerable higher than the `preroll_offset` plus any additional time for pro-active fallback
-# handling, being able to avoid issues with concurrent changes or timings.
-scheduling_window_offset=180
+# The scheduling window defines when the entries of each schedule are queued for play-out. The actual window (scheduling_window_start - scheduling_window_end)
+# should be higher then the `fetching_frequency` to allow proper queuing. Otherwise the fetch might never hit the scheduling window, because the scheduling
+# logic is attached to the fetching logic. 
+# 
+# Following operations are related to the scheduling window:
+# 
+#   - Deletion of schedules/timeslots: Those are only accepted until the **start** of the scheduling window
+#   - Update/Delete/Assignment of playlists and entries: Those are accepted until the **end** of the the scheduling window; existing queued entries are updated
+#   - Pro-active fallback handling: Within the window it is continousely evaluated if some fallback playlist should be applied. The queued items are updated accordingly
+#
+# After the end of the scheduling window the pre-rolling phase starts. It's recommended that the end of the windows is approximately 4x times
+# higher than the preroll_offset, to leave enough space for all 4 fallback scenarios to pre-roll (normal, show, timeslot and station).
+# Note, the values for windows is defined as a offset minus the actual start of the schedule in seconds.
+scheduling_window_start=600
+scheduling_window_end=120
 # Playlist ID which is used for station fallbacks. Only used if no station fallback ID is provided via Steering. "0" means it is disabled.
 scheduling_station_fallback_id=0
+# How many seconds before the actual schedule time the entry should be pre-rolled. Note to provide enough timeout for
+# contents which take longer to load (big files, bad connectivity to streams etc.)
+preroll_offset=30
 
 # Sometimes it might take longer to get a stream connected. Here you can define a viable length.
 # But note, that this may affect the preroll time (see `preroll_offset`), hence affecting the