Commit a5939f88 authored by David Trattnig's avatar David Trattnig
Browse files

Config for scheduling window.

parent 37b41e7f
......@@ -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
......
......@@ -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
......
......@@ -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
......
Supports Markdown
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment