... | @@ -4,7 +4,7 @@ |
... | @@ -4,7 +4,7 @@ |
|
|
|
|
|
## EPIC
|
|
## EPIC
|
|
|
|
|
|
* **Recorder and Cut&Glue Components:** [\*\*https://gitlab.servus.at/aura/meta/-/issues/9 \*\*](https://gitlab.servus.at/aura/meta/-/issues/9 "[EPIC] AURA Recorder and Cut&Glue Components")
|
|
* **Recorder and Cut&Glue Components:** [**https://gitlab.servus.at/aura/meta/-/issues/9**](https://gitlab.servus.at/aura/meta/-/issues/9 "[EPIC] AURA Recorder and Cut&Glue Components")
|
|
* **Repeating Shows & Schedules:** [**https://gitlab.servus.at/aura/meta/-/issues/15**](https://gitlab.servus.at/aura/meta/-/issues/15 "[EPIC] Repeating Shows & Schedules")
|
|
* **Repeating Shows & Schedules:** [**https://gitlab.servus.at/aura/meta/-/issues/15**](https://gitlab.servus.at/aura/meta/-/issues/15 "[EPIC] Repeating Shows & Schedules")
|
|
|
|
|
|
## Use Cases:
|
|
## Use Cases:
|
... | @@ -140,7 +140,35 @@ Die Aufnahme soll möglichst zeitnah nach einer Sendung bereitstehen für |
... | @@ -140,7 +140,35 @@ Die Aufnahme soll möglichst zeitnah nach einer Sendung bereitstehen für |
|
_Hackathon Freistadt Juli 2021: Im Moment ist bei Wiederholungen nicht erkennbar, was wiederholt wird (aktuell: die letzte Episode der Reihe, die keine Wiederholung war). (Implizite Logik)\
|
|
_Hackathon Freistadt Juli 2021: Im Moment ist bei Wiederholungen nicht erkennbar, was wiederholt wird (aktuell: die letzte Episode der Reihe, die keine Wiederholung war). (Implizite Logik)\
|
|
In Zukunft wird das explizit angegeben. (Kein UI-Feld, sondern intern)_
|
|
In Zukunft wird das explizit angegeben. (Kein UI-Feld, sondern intern)_
|
|
|
|
|
|
… **_to be defined …_**
|
|
Wir haben jetzt ein `is_repetition`-Feld bei den Schedules und eins bei den
|
|
|
|
Timeslots.
|
|
|
|
|
|
|
|
Im Schedule bedeutet dass der Sendeplatz die Wiederholung einer Sendung ist, im
|
|
|
|
Timeslot bedeutet dass diese eine Timeslot eine Wiederholung ist. Aber beide
|
|
|
|
haben keine Information darüber was wiederholt wird.
|
|
|
|
|
|
|
|
Ich denke wir könnten bei den Timeslots das Feld `repetition_of` einführen, der
|
|
|
|
dann eine ForeignKey auf ein Timeslot ist. (`is_repetition` könnten wir dann
|
|
|
|
entfernen.)
|
|
|
|
|
|
|
|
Damit würde würde dann der Tank wissen, dass für diesen Timeslot nicht eine
|
|
|
|
Playlist oder Datei braucht sondern aus den Aufnahmen die Zeit von Start bis
|
|
|
|
Ende des Timeslots, der wiederholt wird, holen muss und diese Aufnahme dann
|
|
|
|
speichert.
|
|
|
|
|
|
|
|
Mir ist es lieber wir habe explizite Information darüber was wiederholt wird
|
|
|
|
und nicht implizit dass es die letzte Aufnahme einer nicht als Wiederholung
|
|
|
|
gekennzeichnetes Timeslots.
|
|
|
|
|
|
|
|
Wir müsste dann nur im Dasboard den Timeslot als Wiederholung definieren. Und
|
|
|
|
das für jeden Timeslot der eine Wiederholung ist.
|
|
|
|
|
|
|
|
Um es auf Schedule-Ebene zu ermöglichen, könnten wir etwas ähnliches machen und
|
|
|
|
ein `repetition_of`-Feld definieren, dar dann eine ForeignKey auf Schedule ist,
|
|
|
|
wir würden aber etwas zusätliches brauchen, um explizit zu definieren, was wann
|
|
|
|
wiederholt wird.
|
|
|
|
|
|
|
|
… **_to be discussed …_**
|
|
|
|
|
|
###
|
|
###
|
|
|
|
|
... | | ... | |