Refactor playlists not allowing combinations of different entry types
The original Tank Playlist API and Dashboard UI was designed with a generic approach in mind. This allows mixing of all entry types in a single playlist. That means a playlist can consist of:
- Files entries
- Analog Source entries
- Stream entries
This results in two types of challenges:
1. User Experience challenges: The user cannot expect what happens when some source fails. For example live sources are typically meant to be played at a fixed broadcast window. Files sources on the other hand are typically a queue, which should allow adding new entries on the fly. Given following example of a playlist:
00:00 - file#1
00:05 - file#2
00:10 - file#3
00:15 - live broadcast
00:30 - file#5
00:45 - file#6
As a consequence playlists consist of two different types of artifact: a.) queueable and b.) fixed frame audio sources which naturally don't belong together in the same playlist.
When some of the first files fail to be played for any reason, there is a gap between files and live source. This is automatically filled with audio from the silence detector. So far so good. But the user might not be aware when the live broadcast starts playing, as in its perception it should be after file#3. Likely, the host misses to broadcast the live segment in time. It think it's imaginable, that this can cause multiple reasons for frustration.
YAGNI: After gathering feedback from people from different radios, the uses case of mixing playlist entry types seems not to be required.
When there are situations to mix pre-produced content with live content, this always can be done using a media player in the live studio.
2. Technical challenges: While the current implementation of Engine actually manages to provide this feature based on the given API, the resulting code is relatively complex in contrast to the benefits of this functionality. Also, building means of intervention (during a show) on top of that raises the bar for complexity further. Therefore it breaks the KISS principle.
Solution: This ticket aims to remove such feature altogether, allowing a much lighter implementation. Also, it serves for better understanding the underlying mechanics for end-users. I am suggesting to only allow a playlist consisting with one of these:
- Multiple file entries.
- A single live source entry
- A single stream source entry
(Required UI restrictions will be provided at a later stage)