Removed obsolete station fb-pl. #43

configuration/sample-development.engine.ini

@@ -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 #
 #######################

configuration/sample-docker.engine.ini

@@ -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"
 

configuration/sample-production.engine.ini

@@ -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"
 

modules/scheduling/calender_fetcher.py

@@ -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)