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

Removed obsolete station fb-pl. #43

parent 0751cf0e
......@@ -78,45 +78,41 @@ api_engine_store_health="http://localhost:8008/api/v1/source/health/${ENGINE_NUM
[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=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.
fetching_frequency=30
# The scheduling window defines when the entries of each schedule are queued for play-out in an ideal scenario.
# 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
# - Deletion of 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).
# After the end of the scheduling window the pre-loading phase starts.
# 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
scheduling_window_end=15
# 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
preload_offset=10
# 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
# But note, that this may affect the preloading time (see `preload_offset`), hence affecting the
# overall playout, it's delays and possible fallbacks
input_stream_retry_delay=1
input_stream_max_retries=10
input_stream_buffer=3.0
# sets the time how long we have to fade in and out, when we select another mixer input
# values are in seconds
# this is solved on engine level because it is kind of tough with liquidsoap
[fading]
# Sets the time how long we have to fade in and out, when we select another mixer input values are in seconds
fade_in_time="0.5"
fade_out_time="2.5"
#######################
# Liquidsoap Settings #
#######################
......
......@@ -78,40 +78,37 @@ api_engine_store_health="http://127.0.0.1:8008/api/v1/source/health/${ENGINE_NUM
[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
# 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.
# The scheduling window defines when the entries of each schedule are queued for play-out in an ideal scenario.
# 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
# - Deletion of 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).
# After the end of the scheduling window the pre-loading phase starts.
# 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
scheduling_window_end=60
# 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
preload_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
# But note, that this may affect the preloading time (see `preload_offset`), hence affecting the
# overall playout, it's delays and possible fallbacks
input_stream_retry_delay=1
input_stream_max_retries=10
input_stream_buffer=3.0
# sets the time how long we have to fade in and out, when we select another mixer input
# values are in seconds
# this is solved on engine level because it is kind of tough with liquidsoap
[fading]
# Sets the time how long we have to fade in and out, when we select another mixer input values are in seconds
fade_in_time="0.5"
fade_out_time="2.5"
......
......@@ -78,40 +78,37 @@ api_engine_store_health="http://localhost:8008/api/v1/source/health/${ENGINE_NUM
[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
# 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.
# The scheduling window defines when the entries of each schedule are queued for play-out in an ideal scenario.
# 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
# - Deletion of 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).
# After the end of the scheduling window the pre-loading phase starts.
# 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
scheduling_window_end=60
# 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
preload_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
# But note, that this may affect the preloading time (see `preload_offset`), hence affecting the
# overall playout, it's delays and possible fallbacks
input_stream_retry_delay=1
input_stream_max_retries=10
input_stream_buffer=3.0
# sets the time how long we have to fade in and out, when we select another mixer input
# values are in seconds
# this is solved on engine level because it is kind of tough with liquidsoap
[fading]
# Sets the time how long we have to fade in and out, when we select another mixer input values are in seconds
fade_in_time="0.5"
fade_out_time="2.5"
......
......@@ -149,7 +149,6 @@ class CalendarFetcher:
"""
# store fetched entries => do not have to fetch playlist_id more than once
fetched_entries=[]
local_station_fallback_id = str(self.config.get("scheduling_station_fallback_id"))
try:
for schedule in self.fetched_schedule_data:
......@@ -167,13 +166,6 @@ class CalendarFetcher:
schedule["show_fallback"] = self.fetch_playlist(show_fallback_id, fetched_entries)
schedule["station_fallback"] = self.fetch_playlist(station_fallback_id, fetched_entries)
# If Steering doesn't provide a station fallback, the local one is used
if not schedule["station_fallback"] and int(local_station_fallback_id) > 0:
schedule["station_fallback_id"] = local_station_fallback_id
schedule["station_fallback"] = self.fetch_playlist(local_station_fallback_id, fetched_entries)
if schedule["station_fallback"]:
self.logger.info("Assigned playlist #%s as local station fallback to schedule #%s" % (local_station_fallback_id, schedule["schedule_id"]))
except Exception as e:
self.logger.error("Error while fetching playlists from API endpoints: " + str(e), e)
......
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