diff --git a/configuration/sample-development.engine.ini b/configuration/sample-development.engine.ini index 02bc181557c0b732be4fcb12928091918e3d4b91..d06b3c73fa16ec6d719e9e81e25fe9585634dc69 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 808e214c36088477103c261a4b3a44205888ab64..a92c7e8bdfc3a5115c110d34e57aae50351d0261 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 361791dccdfc9c7017836fd74a6b7af0a48c40ad..4fb39a51b6004ed96ec95b0283c9b6b899e52faf 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