... | @@ -5,6 +5,7 @@ |
... | @@ -5,6 +5,7 @@ |
|
| 2022-05-04 | Erstes Team Review | Ernesto, Christian, Ole, David | Draft |
|
|
| 2022-05-04 | Erstes Team Review | Ernesto, Christian, Ole, David | Draft |
|
|
| 2022-05-31 | Referenz zu Epic | David | Draft |
|
|
| 2022-05-31 | Referenz zu Epic | David | Draft |
|
|
| 2022-11-17 | Update offene Punkte, Tank spec | David | Draft |
|
|
| 2022-11-17 | Update offene Punkte, Tank spec | David | Draft |
|
|
|
|
| 2022-12-14 | Input von Christian im AuraTeam am 13.12.22 | David | Draft |
|
|
|
|
|
|
## EPIC
|
|
## EPIC
|
|
|
|
|
... | @@ -36,6 +37,7 @@ |
... | @@ -36,6 +37,7 @@ |
|
* <span dir="">Tank und Steering:</span> Muss Steering wissen, dass es eine Aufnahme gibt? Dies aktiviert die Möglichkeit die Episode als Wiederholung auszuspielen. Reicht es, wenn es Dashboard weiß?
|
|
* <span dir="">Tank und Steering:</span> Muss Steering wissen, dass es eine Aufnahme gibt? Dies aktiviert die Möglichkeit die Episode als Wiederholung auszuspielen. Reicht es, wenn es Dashboard weiß?
|
|
* Wenn eine Aufnahme im Tank bereit steht, braucht es ein Event an Dashboard? Websocket?
|
|
* Wenn eine Aufnahme im Tank bereit steht, braucht es ein Event an Dashboard? Websocket?
|
|
* **Was ist der treibende Dienst:** Bisher gehen wir von einem Ansatz aus, dass Cut&Glue für den Export der Aufnahmen nach Tank verantwortlich ist. Wie sollen hier Outages des Cut&Glue Services behandelt werden? Ist hier Cut&Glue in der Verantwortung, dass diese Nachgereit werden oder holt sich diese Tank je nach Bedarf? In einer idealen Architektur würde ich sagen, das Tank über seine Wahrheit bescheid weiß und für seine "innerliche Integrität" selbst sorgt. Somit bei externen Diensten nachfragt, wenn er was braucht. Dies wirft jedoch das grundlegende Import/Export Konzept durcheinander.
|
|
* **Was ist der treibende Dienst:** Bisher gehen wir von einem Ansatz aus, dass Cut&Glue für den Export der Aufnahmen nach Tank verantwortlich ist. Wie sollen hier Outages des Cut&Glue Services behandelt werden? Ist hier Cut&Glue in der Verantwortung, dass diese Nachgereit werden oder holt sich diese Tank je nach Bedarf? In einer idealen Architektur würde ich sagen, das Tank über seine Wahrheit bescheid weiß und für seine "innerliche Integrität" selbst sorgt. Somit bei externen Diensten nachfragt, wenn er was braucht. Dies wirft jedoch das grundlegende Import/Export Konzept durcheinander.
|
|
|
|
* Review, Entscheidungen und Einarbeitung der Vorschläge von Christian im AuraTeam am 13.12.2022
|
|
|
|
|
|
##
|
|
##
|
|
|
|
|
... | @@ -107,7 +109,7 @@ Schneiden: |
... | @@ -107,7 +109,7 @@ Schneiden: |
|
|
|
|
|
Concatten mit μs genauem Längenvergleich:
|
|
Concatten mit μs genauem Längenvergleich:
|
|
|
|
|
|
`sox chopped/\\\\\\\* final.flac`
|
|
`sox chopped/\\\\\\\\\\\\\\\* final.flac`
|
|
|
|
|
|
`A=$(soxi -D input.flac)` \
|
|
`A=$(soxi -D input.flac)` \
|
|
`B=$(soxi -D final.flac)`\
|
|
`B=$(soxi -D final.flac)`\
|
... | @@ -187,4 +189,21 @@ Das Dashboard soll verschiedene Varianten an Wiederholungskonzepten anbieten: |
... | @@ -187,4 +189,21 @@ Das Dashboard soll verschiedene Varianten an Wiederholungskonzepten anbieten: |
|
|
|
|
|
### Engine Core
|
|
### Engine Core
|
|
|
|
|
|
… **_to be defined …_** |
|
… **_to be defined …_**
|
|
\ No newline at end of file |
|
|
|
|
|
## **Historie**
|
|
|
|
|
|
|
|
#### Aura Team, 2022-12-13
|
|
|
|
|
|
|
|
Vorschläge Christian zu Cut&Glue:
|
|
|
|
|
|
|
|
- Plugin System in Go gibt es nicht wirklich.
|
|
|
|
- 2 x recorder
|
|
|
|
- 2 x cut & glue
|
|
|
|
- load-balancer (z.B. selbe maschine wie tank), proxy macht live-check, kann mit "ha proxy" fertig configuriert werden. überlegung vielleicht auch als teil von tank/go
|
|
|
|
- agent/job würde ein pull auf cut&glue machen; in den tank importieren.
|
|
|
|
- netzwerk-shares vermeiden: hat keinen error kanal. zB. "etwas ist nicht verfügbar" oder timeout handling gibt's nicht. wenn was hängt, hängt alles. Alternative: Daten über HTTP ausliefern. Cut&Glue wäre dann Teil des Recorder Repos, am Besten als zwei Prozesse/Services. Recorder höhere I/O Priorität als Cut&Glue.
|
|
|
|
- Cut & Glue Retention kann dann nicht mehr sein als die Recorder Retention.
|
|
|
|
- Tank ist rein passiv, der Agent importiert stündlich z.B. immer "10nach". Kann z.B. als Teil des Cut&Glue Repos in `contrib` liegen. Nur als Beispiel, weil jedes Radio das Archiv wohl anders macht.
|
|
|
|
- Keine Aufnahmen ins Filesystem schreiben, kein "Caching" von Requests "in progress" via Filesystem. Wenn dann über ein Caching im RAM. Aber auch nicht unbedingt nötig.
|
|
|
|
- Im Tank gibt es keine Retention / Entscheidungsmöglichkeit was gelöscht werden soll. Wir brauchen da halt ein Monitoring, falls die Festplatte voll wird. Hier kann nicht einfach die ältesten Files löschen (vgl "Jingles"). |
|
|
|
\ No newline at end of file |