style(docs): auto-formatting

docs/developer-guide.md

@@ -27,7 +27,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 entries.
 - 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.
 
@@ -39,7 +39,7 @@ There's a convenience script to start all of the three main dependencies (Steeri
 
 ## Engine Components
 
-*...TBD...*
+_...TBD..._
 
 ## Running for Development
 
@@ -65,7 +65,7 @@ Now run the Engine:
 ~/code/aura/engine$ ./run.sh
 ```
 
-If your IDE of choice is *Visual Studio Code*, then there are launch settings provided in `.vscode/launch.json`.
+If your IDE of choice is _Visual Studio Code_, then there are launch settings provided in `.vscode/launch.json`.
 
 ## Testing
 
@@ -97,53 +97,52 @@ point in time and the involved phase before:
 ```
 
 - **Scheduling Window**: Within the scheduling window any commands for controlling
-    the mixer of the soundsystem are prepared and queued.
+  the mixer of the soundsystem are prepared and queued.
 
-    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
-    scheduling window has started.
+  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
+  scheduling window has started.
 
-    The start and the end of the window is defined by the start of the timeslot minus
-    a configured amount of seconds (see `scheduling_window_start` and `scheduling_window_end`
-    in `engine.ini`). The actual start of the window is calcuated by (timeslot start - window start)
-    and the end by (timeslot end - window end)
+  The start and the end of the window is defined by the start of the timeslot minus
+  a configured amount of seconds (see `scheduling_window_start` and `scheduling_window_end`
+  in `engine.ini`). The actual start of the window is calcuated by (timeslot start - window start)
+  and the end by (timeslot end - window end)
 
-    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`).
+  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`).
 
-    > 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.
+  > 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.
 
-    > Note: If you delete any existing timeslot in Dashboard/Steering this is only reflected in Engine until the start
-    of the scheduling window. The scheduling window is defined by the start of the timeslot minus a configured offset
-    in seconds. This is limitation is required to avoid corrupted playout in case audio content has been
-    preloaded or started playing already.
+  > Note: If you delete any existing timeslot in Dashboard/Steering this is only reflected in Engine until the start
+  > of the scheduling window. The scheduling window is defined by the start of the timeslot minus a configured offset
+  > 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
-    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`).
+  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 entry
+  should have started in the past already) the offset is ignored and the entry 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
-    are scenario where playout start later than planned e.g. during startup of the engine during a timeslot
-    or due to some severe connectivity issues to some external stream.
+  > 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
+  > are scenario where playout start later than planned e.g. during startup of the engine during a timeslot
+  > 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 analog
-    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.
-
-    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>.
+  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 analog
+  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.
 
+  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>.
 
 ## Docker