From c9d09ee50e0c2234c9cd868df93eb6919dfe2e78 Mon Sep 17 00:00:00 2001
From: David Trattnig <david@subsquare.at>
Date: Mon, 2 Oct 2023 15:37:49 +0200
Subject: [PATCH] docs: use playlist item instead of entry
---
config/sample.engine.docker.ini | 6 +++---
config/sample.engine.ini | 6 +++---
docs/developer-guide.md | 18 +++++++++---------
3 files changed, 15 insertions(+), 15 deletions(-)
diff --git a/config/sample.engine.docker.ini b/config/sample.engine.docker.ini
index 44f08783..6d1ba2cb 100644
--- a/config/sample.engine.docker.ini
+++ b/config/sample.engine.docker.ini
@@ -70,13 +70,13 @@ audio_playlist_folder="/var/audio/playlist"
engine_latency_offset="${AURA_ENGINE_LATENCY_OFFSET}"
# How often should the calendar be fetched in seconds. This determines the time of the last changes applied, before a specific show is aired
fetching_frequency=30
-# The scheduling window defines when the entries of each timeslot are queued for play-out. The windows start at (timeslot.start - window_start) seconds
+# The scheduling window defines when the items of each timeslot are queued for play-out. The windows start at (timeslot.start - window_start) seconds
# and ends at (timeslot.end - window.end) seconds. Its also worth noting, that timeslots can only be deleted before the start of the window.
scheduling_window_start=60
scheduling_window_end=60
-# How many seconds before the actual schedule time the entry should be pre-loaded. Note to provide enough timeout for
+# How many seconds before the actual schedule time the item should be pre-loaded. Note to provide enough timeout for
# contents which take longer to load (big files, bad connectivity to streams etc.). If the planned start time is in
-# the past the offset is ignored and the entry is played as soon as possible
+# the past the offset is ignored and the item is played as soon as possible
preload_offset=15
# Sometimes it might take longer to get a stream connected. Here you can define a viable length.
# But note, that this may affect the preloading time (see `preload_offset`), hence affecting the
diff --git a/config/sample.engine.ini b/config/sample.engine.ini
index 875955bf..c18e4abe 100644
--- a/config/sample.engine.ini
+++ b/config/sample.engine.ini
@@ -70,13 +70,13 @@ audio_playlist_folder="../engine-core/audio/playlist"
engine_latency_offset=0.5
# How often should the calendar be fetched in seconds. This determines the time of the last changes applied, before a specific show is aired
fetching_frequency=30
-# The scheduling window defines when the entries of each timeslot are queued for play-out. The windows start at (timeslot.start - window_start) seconds
+# The scheduling window defines when the items of each timeslot are queued for play-out. The windows start at (timeslot.start - window_start) seconds
# and ends at (timeslot.end - window.end) seconds. Its also worth noting, that timeslots can only be deleted before the start of the window.
scheduling_window_start=60
scheduling_window_end=60
-# How many seconds before the actual schedule time the entry should be pre-loaded. Note to provide enough timeout for
+# How many seconds before the actual schedule time the item should be pre-loaded. Note to provide enough timeout for
# contents which take longer to load (big files, bad connectivity to streams etc.). If the planned start time is in
-# the past the offset is ignored and the entry is played as soon as possible
+# the past the offset is ignored and the item is played as soon as possible
preload_offset=15
# Sometimes it might take longer to get a stream connected. Here you can define a viable length.
# But note, that this may affect the preloading time (see `preload_offset`), hence affecting the
diff --git a/docs/developer-guide.md b/docs/developer-guide.md
index 92590062..b2e69371 100644
--- a/docs/developer-guide.md
+++ b/docs/developer-guide.md
@@ -30,7 +30,7 @@ Starting development of engine can be quite tedious, as it requires all most all
For example:
- 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.
+ which hold the actual information on playlists and their items.
- Dashboard, to have a neat interface, being able to programme the timeslots
- Tank, to get the references to audio files and other audio sources. Plus the actual files.
@@ -113,7 +113,7 @@ point in time and the involved phase before:
Only until the start of the window, timeslots can be updated or removed via external API Endpoints
(e.g. using Steering or Dashboard). Until here any changes on the timeslot itself will be reflected
in the actual play-out. This only affects the start and end time of the "timeslot" itself.
- It does not involve related playlists and their entries. Those can still be modified after the
+ It does not involve related playlists and their items. Those can still be modified after the
scheduling window has started.
The start and the end of the window is defined by the start of the timeslot minus
@@ -123,7 +123,7 @@ point in time and the involved phase before:
During the scheduling window, the external API Endpoints are pulled continuously, to
check for updated timeslots and related playlists. Also, any changes to playlists and
- its entries are respected within that window (see `fetching_frequency` in `engine.ini`).
+ its items are respected within that window (see `fetching_frequency` in `engine.ini`).
> Important: It is vital that the the scheduling window is wider than the fetching frequency.
> Otherwise one fetch might never hit a scheduling window, hence not being able to schedule stuff.
@@ -133,13 +133,13 @@ point in time and the involved phase before:
> in seconds. This is limitation is required to avoid corrupted playout in case audio content has been
> preloaded or started playing already.
-- **Queuing and Pre-Loading**: Before any playlist entries of the timeslot can be turned into
+- **Queuing and Pre-Loading**: Before any playlist items of the timeslot can be turned into
sound, they need to be queued and pre-loaded. Ideally the pre-loading happens somewhat before
the scheduled play-out time to avoid any delays in timing. Set the maximum time reserved for
pre-loading in your configuration (compare `preload_offset`in `engine.ini`).
- If there is not enough time to reserve the given amount of time for preloading (i.e. some entry
- should have started in the past already) the offset is ignored and the entry is played as soon as possible.
+ If there is not enough time to reserve the given amount of time for preloading (i.e. some playlist item
+ should have started in the past already) the offset is ignored and the item is played as soon as possible.
> Important: To ensure proper timings, the offset should not exceed the time between the start of
> the scheduling-window and the start of the actual timeslot playout. Practically, of course there
@@ -147,10 +147,10 @@ point in time and the involved phase before:
> or due to some severe connectivity issues to some external stream.
- **Play-out**: Finally the actual play-out is happening. The faders of the virtual mixers are pushed
- all the way up, as soon it is "time to play" for one of the pre-loaded entries.
- Transitions between playlist entries with different types of sources (file, stream and line
+ all the way up, as soon it is "time to play" for one of the pre-loaded items.
+ Transitions between playlist items with different types of sources (file, stream and line
inputs) are performed automatically. At the end of each timeslot the channel is faded-out,
- no matter if the total length of the playlist entries would require a longer timeslot.
+ no matter if the total length of the playlist items would require a longer timeslot.
If for some reason the playout is corrupted, stopped or too silent to make any sense, then
this <u>triggers a fallback using the silence detector</u>.
--
GitLab