implement proper rereleasing process

[saerdnaer]

Verschoben aus voc/voctoweb#40

Variante A:

• beim ersten Release eines Encoding-Tickets die media.ccc.de recording_id die beim releasen zurück kommt in den tracker ins entsprechende Encoding-Ticket zurückschreiben.
• bei einem Rerelease dann anstatt POST recording ein PUT recording/ machen
  Offene Frage:
• Es gibt Fälle in denen ein Encoding Ticket mehrere Recordings auf media erzeugt: Bei mehreren Audio-Tracks wird aktuell im releasing Skript gesplittet und nicht im Tracker...
  @a-tze Soll das so bleiben oder wolltet ihr das ändern?

Variante B:

• Release eines Encoding-Tickets wie gehabt.
• wenn beim Rerelease via POST nen Fehler von der Validation zurück kommt weil es für diesen Mime-Type + Sprache + Quality-Flag (TODO ist das der Fall?) oder den Filename statt dessen ein PUT recording/ machen

Variante C:

• Beim Release eines Encoding-Tickets wird im Ticket ein Flag released_to_media=yes gesetzt
• Bei einem Rerelease wird auf Basis dieses Flags entschieden ob POST oder PUT das richtige ist.
• Bei PUT muss man sich vorher über die UUID des Events die Recordings hohlen und schauen welche Recordings man konkret überschreiben muss. Lässt sich über den Filename relativ einfach rausfinden...

[a-tze]

@saerdnaer das wollten wir nie wirklich haben, wir warten nach wie vor auf einen web player der das kann. dann fällt das rumgemuxe weg und es sollte dann wieder eine 1:1 beziehung zwischen tracker ticket und recording auf media geben. derzeit ist das allerdings nicht so, korrekt.

[saerdnaer]

@a-tze Naja, wir könnten halt auch wieder ne 1:1 Beziehung zwischen Encoding Tickets uns Files herstellen, wenn wir das Splitten/Remuxing im Tracker abbilden. Weißt du noch warum man sich damals dagegen entschiedenen hatte?

[saerdnaer]

Habe oben Variante B + C hinzugefügt.

[a-tze]

@saerdnaer Splitting im Tracker hat einige gravierende Nachteile, zumindest in der aktuellen, "starren" Pipeline. Die zugegeben hohe Komplexität, die das Releasing für multilang derzeit hat, würde dann nur über den gesamten Prozess ausgestreut, was die Sache nicht wirklich besser macht. Und sobald das web player problem gelöst ist, haben wir ne große Leiche im Keller.

Bei einem der letzten Events gabs mal audio-only tickets der Übersetzerspuren. Das war sehr unschön zu handlen.

[derpeter]

Ich verstehe leider nicht was mit das Ticket sagen soll. Kann man das als "rereleasing sollte funktionieren ohne event im backend zu löschen" zusammen fassen?.
Keiner der Varianten wirkt wirklich greifbar das generelle rereleasing steht aber eh auf der todo.
Sollte ich das missverstanden haben bitte neues Ticket mit korrekter Beschreibung aufmachen

[derpeter]

@saerdnaer da 6 Tage keine Antwort an würde ich das heute Abend closen

[derpeter]

10 days without replay => closed. Please open a new issue if problem still exists

[saerdnaer]

Zur Semantik: Pro conference gibt es mehrere events, an denen wiederum mehrere recordings hängen.

Wie sieht der aktueller rereleasing Prozess aus? Muss man nur die recordings löschen, oder das komplette event inklusive recordings?

[saerdnaer]

Das Publishing Skript speichert inzwischen die Recording ID als Voctoweb.RecordingId.Master im Encoding-Ticket im Tracker ab. [1]
Wenn aus einem Encoding Ticket aber mehrere Files auf media werden (Master mit zwei Audio Tracks + Orginal (single audio track) + Translated (single audio track) landen die Recording IDs der beiden letzteren Files nicht im Tracker.

@derpeter Ich glaube du musst dazu noch in https://github.com/voc/publishing/blob/b38536779add1945d60ce5c3f420f85ffe0bf3c3/src/script_H_publishing.py#L264-L267 die selbe Zeile wie bei [1] hinzufügen. Also das 'master' muss man natürlich noch durch anders pro file ersetzen.

Bei einem Re-release kann man über die Recording IDs aus dem Tracker die bestehenden Recordings updaten und muss nicht löschen+neu anlegen. Sprich anstatt POST ein PUT bzw. PATCH request, vgl. https://github.com/voc/voctoweb/blob/master/app/controllers/api/recordings_controller.rb#L23-L48

Wenn der Master re-released wird muss man dann eben auch noch die Metadaten des events + Thumbnails updaten, siehe auch Kommentar von Texec in #22 (comment)

Bonus-Punkte/to discuss:
Aktuell wird die voctoweb Event-ID nicht im Tracker abgespeichert, vgl. [3]. Ist im Prinzip nicht so schlimm, da man inzwischen das event in voctoweb auch per GUID nachschlagen kann. Allerdings wäre es trotzdem sinnvoll die voctoweb Event-ID mit abzuspeichern, damit das Skript weiß das es das Event schon angelegt hat.

[saerdnaer]

Use case: Ein Vortrag der bereits auf Media und YouTube veröffentlicht ist, muss neu released werden.

(Beschreibung der Entities: https://github.com/voc/voctoweb/README#apis )

Aktuelles Vorgehen:

• Media/voctoweb:
  • komplettes Event (inklusive Recordings) auf Media löschen
  • im Tracker: recording_id und andere Properties die der Releasing Worker angelegt hat entfernen
    • Status zurücksetzen
• YouTube:
  • Alle zugehörigen Releases (ggf. mehrere Sprachversionen) löschen oder unlisten
  • Videos neu releasen – dadurch neue YouTube URLs
  • ggf. Beschreibung der alten Videos anpassen und dadurch 'manuellen Redirct' zu den neuen Version einrichten

Varianten: Problem ist nicht gravierend genug: Rererelease nur bei Media

Probleme:

• Recordings die nicht über Tracker in Media angelegt wurden (Slides PDF, Subtitles) gehen beim Löschen des Events verloren

[a-tze]

Siehe SHA, evt. wäre es für den Media-Fall erstmal ausreichend, den HTTP error 422 abzufangen und dann die Metadaten nochmal per PUT/POST/whatever als überschreib-Operation zu schicken.