# 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=30
# The scheduling window defines when the entries of each schedule are queued for play-out in an ideal scenario.
# The scheduling window defines when the entries of each timeslot 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.
...
...
@@ -88,7 +88,7 @@ fetching_frequency=30
# - Update/Delete/Assignment of playlists and entries: Those are accepted until the **end** of the the scheduling window; existing queued entries are updated
#
# 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.
# Note, the values for windows is defined as a offset minus the actual start of the timeslot in seconds.
scheduling_window_start=120
scheduling_window_end=15
# How many seconds before the actual schedule time the entry should be pre-rolled. Note to provide enough timeout for
# 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 in an ideal scenario.
# The scheduling window defines when the entries of each timeslot 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.
...
...
@@ -88,7 +88,7 @@ fetching_frequency=300
# - Update/Delete/Assignment of playlists and entries: Those are accepted until the **end** of the the scheduling window; existing queued entries are updated
#
# 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.
# Note, the values for windows is defined as a offset minus the actual start of the timeslot in seconds.
scheduling_window_start=600
scheduling_window_end=60
# How many seconds before the actual schedule time the entry should be pre-rolled. Note to provide enough timeout for
# 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 in an ideal scenario.
# The scheduling window defines when the entries of each timeslot 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.
...
...
@@ -88,7 +88,7 @@ fetching_frequency=300
# - Update/Delete/Assignment of playlists and entries: Those are accepted until the **end** of the the scheduling window; existing queued entries are updated
#
# 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.
# Note, the values for windows is defined as a offset minus the actual start of the timeslot in seconds.
scheduling_window_start=600
scheduling_window_end=60
# How many seconds before the actual schedule time the entry should be pre-rolled. Note to provide enough timeout for
- Steering, to get the main incredient of an play-out engine: schedules (or "timeslots" in Steering terms),
which hold the actual information on playlists and their entries.
- Dashboard, to have a neat interface, being able to programm the schedules
- Dashboard, to have a neat interface, being able to programm the timeslots
- Tank, to get the references to audio files and other audio sources. Plus the actual files.
If you need to test and develop against the Engine's API you'll also need to get the `engine-api` project running.
...
...
@@ -63,7 +63,7 @@ When you start Engine the following is happening:
2. Python `run.py`: Start Liquidsoap.
3. Liquidsoap: When Liquidsoap finished its startup, it creates a socket file as configured in `socketdir` of `engine.ini`.
4. Python `src/core/liquidsoap/client.py`: Connects to that socket file.
5. Python `src/schedulung/scheduler.py`: Continously loads schedules from the API endpoints, stores them in the local database and starts the playout as per the schedules.
5. Python `src/schedulung/scheduler.py`: Continously loads timeslots from the API endpoints, stores them in the local database and starts the playout as per the timeslots.