diff --git a/config/sample.engine.docker.ini b/config/sample.engine.docker.ini
index 44f0878330a1cfb35b839cb2782e886f117339b7..6d1ba2cb21f1fe790cb962685dd0383ef70bb51f 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 875955bf567341bd1dca8459077b5ccc1a3efab0..c18e4abe1430c8a0bb41c7fe91202776f3bd30b7 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 925900624b3c17f658e369b0eed60bd55f594fe1..b2e69371fa4a14860f252cb6af5239e3cb9cde79 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>.