From a5939f8895c3c3126d1199d608f485656e36ed1b Mon Sep 17 00:00:00 2001 From: David Trattnig <david.trattnig@o94.at> Date: Wed, 10 Jun 2020 09:55:00 +0200 Subject: [PATCH] Config for scheduling window. --- configuration/sample-development.engine.ini | 25 +++++++++++++++------ configuration/sample-docker.engine.ini | 25 +++++++++++++++------ configuration/sample-production.engine.ini | 25 +++++++++++++++------ 3 files changed, 54 insertions(+), 21 deletions(-) diff --git a/configuration/sample-development.engine.ini b/configuration/sample-development.engine.ini index 02bc1815..d06b3c73 100644 --- a/configuration/sample-development.engine.ini +++ b/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 diff --git a/configuration/sample-docker.engine.ini b/configuration/sample-docker.engine.ini index 808e214c..a92c7e8b 100644 --- a/configuration/sample-docker.engine.ini +++ b/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 diff --git a/configuration/sample-production.engine.ini b/configuration/sample-production.engine.ini index 361791dc..4fb39a51 100644 --- a/configuration/sample-production.engine.ini +++ b/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 -- GitLab