|
|
|
| Datum | Beschreibung | Author | Status |
|
|
|
|
|-------|--------------|--------|--------|
|
|
|
|
| 2022-05-12 | Erstversion | David | Draft |
|
|
|
|
| 2022-06-27 | Sprint 1 Scope | Ernesto | Vorschlag |
|
|
|
|
| 2022-07-01 | Duplikate entfernt; Tank Anforderungen und Notizen hinzugefügt | David | Draft |
|
|
|
|
| 2022-09-05 | Vorschlag für Playlist | Ernesto | Draft |
|
|
|
|
| 2022-09-13 | Vorschlag für License Types | Ernesto | Draft |
|
|
|
|
| 2022-11-07 | Abschnitt zu Tank, Ergebnisse aus der Besprechung Ole, Ernesto, David am 30.08. Lizenztyp & -halter per Audiodatei | David | Draft |
|
|
|
|
| 2022-12-13 | Ergänzung Input von Christian, AuraTeam 13.12.22 | David | Draft |
|
|
|
|
| 2023-03-21 | Sequenzdiagramme und mehr Details | David | Draft |
|
|
|
|
| 2023-03-22 | Review und Vorschläge zu `timeslot.note.playlist` | Ole, Ernesto, David | Draft |
|
|
|
|
|
|
|
|
## EPIC
|
|
|
|
|
|
|
|
[[AEP08] [EPIC] Extend Tank playlist and metadata management](https://gitlab.servus.at/aura/aura/-/issues/155)
|
|
|
|
|
|
|
|
## Zielsetzung und Anwendungsfälle
|
|
|
|
|
|
|
|
Die Möglichkeit einer Speicherung und Abfrage von Playlistinformationen von vorproduzierten Sendungen vor, während und nach der Ausspielung. Diese Playlist Information ist auf basis von Metadaten automatisch generiert.
|
|
|
|
|
|
|
|
Playlisten können aber auch als user-definierter Freitext zur Verfügung gestellt werden. Ein Beispiel sind die Felder des Radio ORANGE 94.0 Legacy Backends.
|
|
|
|
|
|
|
|
## Referenzen
|
|
|
|
|
|
|
|
<details><summary>Beispiel o94 Backend</summary>
|
|
|
|
|
|
|
|
</details>
|
|
|
|
|
|
|
|
<details><summary>Beispiel o94 Website</summary>
|
|
|
|
|
|
|
|
</details>
|
|
|
|
|
|
|
|
## Feedback & Offene Punkte
|
|
|
|
|
|
|
|
Punkte mit etwas Klarheit:
|
|
|
|
|
|
|
|
- 2023-03-22 Ole/Ernesto/David: Wir führen in Steering ein Feld "`timeslot.note.playlist`" ein. Hinter diesem Feld liegt eine JSON Datenstruktur. Diese Feld kann für Legacy Daten als Freitext verwendet werden, aber auch als strukturiertes Playlistfeld für zukünftige Use Cases.
|
|
|
|
- Maggie: Sammeln von Anforderungen der Radios: Welche Metadaten sollen Medienfiles unterstützen?
|
|
|
|
|
|
|
|
Punkte mit weniger Klarheit:
|
|
|
|
|
|
|
|
- Unklar wie wir mit Metadaten/Playlisten für Live/Line/Streamingquellen umgehen. Diese können nicht in Tank hinterlegt werden, weil Playlisten hier mehr als "Templates" dienen und somit nicht persistent sind. Solche Daten können nur/erst in
|
|
|
|
Steering gespeichert werden. Ernesto: Alternative, das Playlist informationen in der Steering Note gespeichert werden
|
|
|
|
- Ole: Live/Stream quellen sicherstellen, dass eingaben auch einem bestimmten format entsprechen. Minimale UI (start, duration, beschreibung)
|
|
|
|
|
|
|
|
- Konrad: Bei Lohro wurden ab und zu Inhalte veröffentlicht, die auf Basis der Lizenz nicht hätten veröffentlicht werden sollen. Im Rahmen dessen haben wir unser [License Model](https://git.hack-hro.de/lohro/lohrothek/lohrothek-api/-/blob/main/lohrothek/core/models.py#L120) ein bisschen erweitert, auf dass für Lizenzen bestimmte Constraints definiert werden können (z.b. `needs_author` oder `requires_express_permission_for_publication`). So lässt sich dann eine Lizenz wie CC-BY (`needs_author = True`) oder "Alle Rechte vorbehalten" (`requires_express_permission_for_publication = True`) maschinenlesbar beschreiben und eine korrekte Freigabe bei zu lizenzierenden Models (z.B. Bilder) forcieren. Vielleicht ein Denkanstoß, falls wir das Problem irrtümlich oder fahrlässig veröffentlichter Inhalte hier vermeiden wollen :smile:
|
|
|
|
- David: Klärung ob wir meine vorgeschlagene Differenzierung "playlist" und "user_playlist" so brauchen oder ob es bessere Lösungswege gibt. Wir können für die Migration die die vorhandenen "o94 user-defined playlist" als workaround einfach an die vorhandene "timeslot.note" beschreibung dranhängen. als zukünftigen timeslots werden dann aber mit strukturierten playlist-informationen (über die bereitgestellte UI) versehen.
|
|
|
|
- David: Welcher Engine API endpoint soll verwendet werden (playlog vs. trackservice)? Ist das Engine API Datenmodell für die gewählte Lösung passend, soll es verändert oder erweitert werden?
|
|
|
|
- Ole: wichtig ist, das die UI gut gemacht ist, damit die RMs motiviert sind diese auch mit Daten zu füllen.
|
|
|
|
- Ole: Gegencheck mit CBA metadaten, damit wir diese auch beim Upload mitgeben können.
|
|
|
|
|
|
|
|
## Spezifikation
|
|
|
|
|
|
|
|
### Auf Basis von Metadaten generierte Playlisten
|
|
|
|
|
|
|
|
Diese Playlisten bilden sich aus Metadaten die entweder durch Tank oder Engine API bereitgestellt werden.
|
|
|
|
|
|
|
|
Steering verhält sich hier wie ein Proxy der die Anfrage per jRPC an die reweilig relevant Datenquelle weiterleitet (Tank oder Engine API).
|
|
|
|
|
|
|
|
#### Sequenzdiagramm
|
|
|
|
```mermaid
|
|
|
|
sequenceDiagram
|
|
|
|
# Client->>+Steering: GET "user_playlist"
|
|
|
|
# Steering->>+Client: "user_playlist"
|
|
|
|
|
|
|
|
|
|
|
|
Client->>+Steering: GET playlist for timeslot
|
|
|
|
|
|
|
|
Steering->>Steering: Is play-out for timeslot finished already?
|
|
|
|
alt is finished
|
|
|
|
Steering->>Engine API: GET playlogs for timeslot
|
|
|
|
Engine API->>+Steering: return playlogs
|
|
|
|
else is not yet finished
|
|
|
|
Steering->>Tank: GET playlist for timeslot
|
|
|
|
Tank->>+Steering: return playlist
|
|
|
|
end
|
|
|
|
Steering->>+Client: playlist response
|
|
|
|
```
|
|
|
|
|
|
|
|
#### Verschachtelte Playlisten (nested playlists)
|
|
|
|
|
|
|
|
Neben Lizenzinformationen (Art und Rechteinhaber), sollen auch Playlist Informationen pro File gespeichert werden. Diese Playlisten enthalten Metadaten von Aufnahmen oder vorproduzierten Sendungen. In Kombination mit bestehenden Tank Playlisten ergibt sich eine verschachtelte Playlistenstruktur:
|
|
|
|
|
|
|
|
```yaml
|
|
|
|
Tank Playlist
|
|
|
|
L live
|
|
|
|
L stream
|
|
|
|
L audio file 1
|
|
|
|
L audio file 2
|
|
|
|
L JSON data holding another playlist
|
|
|
|
L audio file 3
|
|
|
|
L JSON data holding another playlist
|
|
|
|
```
|
|
|
|
|
|
|
|
#### Datenmodell für Audio Files
|
|
|
|
|
|
|
|
- Neues Feld `license_type` (`TextField`), beeinhaltet Schlüssel der verfügbaren Lizenztypen in Steering
|
|
|
|
- Neues Feld `license_owner` (`TextField`), Freitext
|
|
|
|
- Neues Feld `playlist` (`TextField`), Freitext entweder als validiertes, stringified JSON ([JSON Schema](https://json-schema.org/)) ~~oder [CUE Sheet Format](https://wiki.hydrogenaud.io/index.php?title=Cue_sheet)~~
|
|
|
|
|
|
|
|
|
|
|
|
### Unstrukturierte Playlisten auf Basis von manuellen Eingaben.
|
|
|
|
|
|
|
|
Diese Art von Playlisten werden von Nutzenden als unstrukturierter Freitext eingegeben oder werden per Migration eines Legacy Systems bereitgestellt. Daher kann kein wohldefiniertes Datenschema angenommen werden.
|
|
|
|
|
|
|
|
#### Sequenzdiagramm
|
|
|
|
|
|
|
|
```mermaid
|
|
|
|
sequenceDiagram
|
|
|
|
Client->>+Steering: GET "user_playlist"
|
|
|
|
Steering->>+Client: "user_playlist"
|
|
|
|
``` |
