From e5fbb86ba88f1bd30923fbf5b027955bd45d00a9 Mon Sep 17 00:00:00 2001
From: David Trattnig <david.trattnig@o94.at>
Date: Sun, 28 Jun 2020 01:35:59 +0200
Subject: [PATCH] Improved structure.
---
docs/engine-features.md | 68 +++++++++++++++++++++--------------------
1 file changed, 35 insertions(+), 33 deletions(-)
diff --git a/docs/engine-features.md b/docs/engine-features.md
index 1dbb27d0..9ca724f6 100644
--- a/docs/engine-features.md
+++ b/docs/engine-features.md
@@ -11,8 +11,7 @@ This page gives a more detailed overview of the Aura Engine features and how to
- [Stream to Icecast](#stream-to-icecast)
- [Record output to filesystem](#record-output-to-filesystem)
- [Scheduling](#scheduling)
- - [Fallback Stages](#fallback-stages)
- - [Scheduling Stages](#scheduling-stages)
+ - [Fallback Handling](#fallback-handling)
- [Pro-active Fallback Handling (1st Level Fallback)](#pro-active-fallback-handling-1st-level-fallback)
- [Fallback Handling using the Silence Detector (2nd Level Fallback)](#fallback-handling-using-the-silence-detector-2nd-level-fallback)
- [API Endpoints](#api-endpoints)
@@ -44,8 +43,8 @@ The switching between types of audio source is handled automatically. To learn m
### Analog line-out
-In most scenarios it might be sufficient to broadcast via only one analog stereo output channel.
-If need you can configure up to five stereo pairs.
+In most scenarios it might be sufficient to broadcast via only one analog stereo output.
+If needed you can configure up to five stereo pairs.
### Stream to Icecast
@@ -61,35 +60,9 @@ be configured to save in a different resolution in audio quality.
## Scheduling
-Engine performs scheduling with some handling for extended security, to meet the requirements
-of community radios. It tries to pro-actively reacted to scenarios, where the upload of some
-pre-recorded show has been forgotten, or some live schedule is not taking place.
-
-Usually in such cases the broadcast might end up with some timeslot filled with silence.
-To avoid this, Engine implements multiple levels of fallback handling.
-
-### Fallback Stages
-
-The available fallbacks are evaluated in following order:
-
-1. **Schedule Fallback**: If the show fallback is not assigned, a configured fallback
- playlist for the related timeslot is used.
-
-2. **Show Fallback**: If the schedule for some show has no playlist assigned, the
- playlist assigned as a *show fallback* is used instead. In the dashboard this can
- be done as seen in the screenshot below.
-
- 
-
-3. **Station Fallback**: If everything goes wrong, meaning all the previous fallback
- playlists are missing or are invalid, the *station fallback* will be triggered. This
- fallback type is specified by a playlist ID set in the Engine's configuration
- (see `scheduling_station_fallback_id` in `engine.ini`)
-
-### Scheduling Stages
+Engine provide a scheduling functionality by polling external API endpoints frequently.
-To understand how fallbacks are handled by Engine, it's good to know how the Engine's
-scheduling is structured. Below you see a timline with one schedule planned at a certain
+Scheduling is split into multiple phase. Below you see a timline with one schedule planned at a certain
point in time and the involved phase before:
```
@@ -119,7 +92,7 @@ point in time and the involved phase before:
check for updated schedules and related playlists. Also, any changes to playlists and
its entries are respected within that window (see `fetching_frequency` in `engine.ini`).
- <u>Pro-active fallback handling</u> by verifying the existence of playlists is already
+ <u>Pro-active fallback handling</u> by verifying the existence of playlists is already
happening at this stage.
> Important: It's vital that the the scheduling window is wider than the fetching frequency.
@@ -164,6 +137,35 @@ point in time and the involved phase before:
If for some reason the playout is corrupted, stopped or too silent to make any sense, then
this <u>triggers a 2nd level fallback using the silence detector</u> (see chapter below).
+
+## Fallback Handling
+
+Engine performs scheduling with some additional handling for extended security, to meet the requirements
+of community radios. It tries to pro-actively reacted to scenarios, where the upload of some
+pre-recorded show has been forgotten, or some live schedule is not taking place.
+
+Usually in such cases the broadcast might end up with some timeslot filled with silence.
+To avoid this, Engine implements multiple levels of fallback handling.
+
+To understand how fallbacks are handled by Engine in detail, it's good to know how the Engine's
+scheduling is executed. Read more about the scheduling approach in the chapter above.
+
+The available fallbacks are evaluated in following order:
+
+1. **Schedule Fallback**: If the show fallback is not assigned, a configured fallback
+ playlist for the related timeslot is used.
+
+2. **Show Fallback**: If the schedule for some show has no playlist assigned, the
+ playlist assigned as a *show fallback* is used instead. In the dashboard this can
+ be done as seen in the screenshot below.
+
+ 
+
+3. **Station Fallback**: If everything goes wrong, meaning all the previous fallback
+ playlists are missing or are invalid, the *station fallback* will be triggered. This
+ fallback type is specified by a playlist ID set in the Engine's configuration
+ (see `scheduling_station_fallback_id` in `engine.ini`)
+
### Pro-active Fallback Handling (1st Level Fallback)
This type of fallback handling is performed before the actual playout, within the scheduling
--
GitLab