Umgang mit Programmverschiebungen bei Drag-and-Drop-Zeitplanung

Wenn Sie einen beliebigen Live-TV-Operator fragen, was er sich von einem Planungstool wünschen würde, antwortet er fast ausnahmslos: „Lassen Sie mich einen Kanal so aufbauen, wie ich Dateien in einem Ordner organisiere. Ein Programm reinziehen, dort ablegen, wo ich es haben möchte, fertig.“

Das Problem ist, dass ein Kanalplan kein Ordner ist. Es ist ein rechtlich bindendes Dokument mit strengen Einschränkungen. Zwei Programme können nicht gleichzeitig laufen. Der Encoder kann Eingänge nicht schneller als alle fünf Sekunden umschalten. Ein bereits gestartetes Programm kann nicht bearbeitet werden. Und ein Film, der über Mitternacht hinaus läuft, muss als ein einziges Programm behandelt werden, nicht als zwei Teile an der Tagesgrenze.

Jede Drag-and-Drop-Aktion ist eine potenzielle Regelverletzung, die jederzeit auftreten kann. Dies ist die technische Geschichte, wie der Scheduler von mStudio bedienerfreundliches Drag-and-Drop in eine garantiert rechtsgültige Kanal-Timeline auf AWS MediaLive verwandelt – einschließlich des Moments, in dem ein Operator ein Programm direkt auf ein anderes fallen lässt – und warum das System diese Konflikte automatisch löst, anstatt dem Operator einen Fehler und ein Rätsel zum Lösen zu präsentieren.

Kurzübersicht

Das Geschäftsproblem: Ein Kalender, der kein Kalender ist

Die Kanalplanung sieht aus wie eine Kalendersoftware. Operatoren erwarten, dass sie sich auch so verhält – einen Film in einen 21-Uhr-Slot ziehen, Programme auf der Timeline verschieben, eine Serie in Stapeln hinzufügen und zusehen, wie sich die Episoden hintereinander anordnen. Aber ein Live-Kanalplan unterliegt Einschränkungen, die ein Kalender einfach nicht hat:

• Programme dürfen sich nicht überlappen. Live-TV spielt immer genau eine Sache gleichzeitig ab.
• Der Encoder hat einen Mindestabstand für Aktionen. AWS MediaLive schaltet Eingänge nicht schneller als alle 5 Sekunden um. Planen Sie zwei Programme im Abstand von 4 Sekunden, und die Bereitstellung wird abgelehnt.
• Vergangene Programme können nicht bearbeitet werden. Die Sendezeit ist bereits verstrichen; die Bits sind bereits auf den Bildschirmen der Zuschauer.
• Programme, die über Mitternacht hinausgehen, sind eine Einheit. Ein Film, der von 23:30 bis 01:15 Uhr läuft, muss als ein einziges Programm behandelt werden, nicht als zwei Halbprogramme, die an der Tagesgrenze geteilt werden.

Eine „fast Überlappung“ von zwei Sekunden ist kein Bedienerfehler – sie ist das natürliche Ergebnis des Ziehens zweier Programme, die fast, aber eben nicht ganz, zusammenpassen. Die eigentliche technische Herausforderung besteht darin, „einen Film auf 21 Uhr ziehen“ in „einen rechtsgültigen Kanalplan“ zu übersetzen. Macht man es falsch, stößt der Operator entweder bei jedem Ablegen auf eine Fehlermeldung, oder – schlimmer noch – er entdeckt zur Sendezeit, dass der Encoder einen Teil des Plans stillschweigend abgelehnt hat.

Was „rechtsgültig“ auf AWS MediaLive bedeutet

Damit ein Zeitplan auf MediaLive rechtsgültig ist, müssen benachbarte Programme entweder:

1. Direkt aufeinanderfolgend – null Abstand zwischen ihnen, oder
2. Durch mindestens 5 Sekunden getrennt – der Mindestabstand für Aktionen des Encoders.

Die Falle liegt in allem dazwischen. Eine Lücke von 1 Sekunde, eine Lücke von 3 Sekunden, eine Lücke von 4,9 Sekunden – all das sieht in einer UI völlig in Ordnung aus, und alles davon wird zur Bereitstellungszeit abgelehnt. Schlimmer noch, die Ablehnung ist kein sauberer, atomarer Fehler; sie kann zu einem teilweise bereitgestellten Kanal führen, bei dem einige Planungsaktionen auf MediaLive landeten und andere nicht.

Fügt man eine 1-Sekunden-Sicherheitsspanne für die Takt-Drift zwischen Anwendungsservern und AWS hinzu, so beträgt der praktische Mindestwert 6 Sekunden, nicht 5. Diese einzelne Zahl – MIN_NEIGHBOUR_GAP_MS = 6000 – ist die Konstante, um die das gesamte Konfliktlösungssystem aufgebaut ist.

Warum die offensichtlichen Ansätze scheitern

Bevor man sich auf die automatische Konfliktlösung festlegte, wurden mehrere offensichtlichere Strategien in Betracht gezogen und verworfen:

„Jede Unstimmigkeit ablehnen und den Operator bitten, sie zu lösen.“ Deswegen müssen Operatoren bei jedem Ablegen manuell Snap-Berechnungen durchführen. Ein Fünf-Sekunden-Ziehen wird zu einem Fünf-Minuten-Rätsel, und das Rätsel wird mit wachsender Playlist immer schwieriger. In der Praxis geben Operatoren Drag-and-Drop vollständig auf und greifen auf Tabellenkalkulationen zurück.

„Alles an 5-Minuten-Grenzen ausrichten, damit sich nichts überlappt.“ Dies löst das technische Problem, indem es die Absicht des Operators zerstört. Ein Programm, das um 21:03:15 Uhr beginnen sollte, sollte nicht stillschweigend auf 21:05:00 Uhr springen. Der Zeitplan gehört dem Operator, nicht einer Rundungsfunktion.

„Konflikte zur Bereitstellungszeit statt zur Ablegezeit erkennen.“ Dies fühlt sich in der UI schneller an, verlagert den Fehler aber auf den schlechtesten möglichen Zeitpunkt. Wenn der Operator auf „Deploy“ klickt und „Zeitplan bei Programm 47 abgelehnt“ sieht, hat er die Bearbeitung, die dies verursacht hat, bereits mental hinter sich gelassen.

„Mikrolücken in der UI zulassen und MediaLive sie ablehnen lassen.“ Dies leitet undurchsichtige Encoder-Fehler direkt an den Operator zurück und kann den Kanal in einem halb-bereitgestellten Zustand hinterlassen, der wirklich schwer wiederherzustellen ist.

Der Ansatz, der tatsächlich funktionierte, war die automatische Konfliktlösung zum Zeitpunkt des Ablegens, unter Verwendung deterministischer Regeln – und die sofortige Rückmeldung der korrigierten Timeline an den Operator.

Die Lösung: Ein Vier-Regel-Snap-Algorithmus

Bei jedem Ablegen untersucht ein Snap-Algorithmus jedes Paar benachbarter Programme auf dem betroffenen Kanal – neue-zu-neue, neue-zu-bestehende oder bestehende-zu-bestehende Paare, deren Lücke sich aufgrund des Ablegens geändert hat – und wendet genau eine von vier Regeln basierend auf der Lücke zwischen ihnen an:

• Lücke = 0 → keine Aktion. Direkt aufeinanderfolgend ist zulässig und entspricht fast mit Sicherheit der Absicht des Operators.
• Lücke ≥ 6 Sekunden → keine Aktion. Der Operator hat absichtlich Platz gelassen, wahrscheinlich für eine Tafel oder einen Werbeblock.
• 0 < Lücke < 6 Sekunden → das zweite Programm rückwärts verschieben, um die Lücke auf null zu schließen.
• Negative Lücke (Überlappung) → das zweite Programm um den Überlappungsbetrag vorwärts verschieben.

Entscheidend ist, dass der Algorithmus benachbarte Paare in einem einzigen Vorwärtsdurchlauf über die sortierte Timeline verarbeitet. Jedes verschobene Programm wird sofort zum „vorherigen“ Element für den nächsten Vergleich – so löst sich ein Ablegen, das eine Kettenreaktion von Verschiebungen auslöst, in einem linearen Durchlauf, ohne dass Rekursion erforderlich ist.
Diagramm 1 · Der Snap-Entscheidungsbaum

Systemarchitektur

Der Scheduler ist um einen kleinen, fokussierten Satz von Komponenten herum aufgebaut:

• Das NestJS-Backend (schedule.service.ts) ist für den Snap-Walk, die Kaskaden-Memoisierung und den Schreibvertrag mit MediaLive zuständig.
• Zeitbereichs-Überlappungsabfrage. Wenn ein Ablegen erfolgt, zieht das Backend jedes bestehende Programm heran, dessen Zeitfenster den Bereich des neuen Stapels berührt, plus einen 6-Sekunden-Puffer auf jeder Seite. Da diese Abfrage auf Zeitbereichen und nicht auf Kalenderdaten basiert, werden Programme, die über Mitternacht hinausgehen, identisch zu jedem anderen Programm behandelt – es gibt keine spezielle Logik für Datumsübergänge im System.
• Zusammengeführte Timeline. Die neuen Programm-DTOs und die abgefragten bestehenden Programme werden in einer einzigen sortierten Liste zusammengeführt. Der Snap-Walk läuft gegen diese kombinierte Timeline.
• shiftedExistings Map. Für jedes bestehende Programm, das von einer Verschiebung betroffen ist, erfasst diese Map dessen ursprüngliche Start- und Endzeiten bei der ersten Berührung – und überschreibt sie niemals bei späteren Berührungen. Diese eine Datenstruktur ist es, die mehrstufige Kaskaden sicher macht.
• Lambda DELETE_PROGRAM. Für jedes verschobene Programm, das bereits auf MediaLive bereitgestellt wurde, werden dessen ursprüngliche Zeiten an eine Lambda-Funktion zur Bereinigung gesendet, bevor MongoDB aktualisiert wird.

• MIN_NEIGHBOUR_GAP_MS = 6000 – die einzige Konstante, auf die jede Regel, jede Überlappungsabfrage und jeder Sicherheitspuffer verweist.

   

Wichtige technische Entscheidungen

1. Vier Regeln, ein Durchlauf, keine Sonderfälle. Dieselben vier Regeln decken jedes Szenario ab, das ein Operator erstellen kann: ein neues Programm, das zwischen zwei bestehende fällt, zwei neue Programme, die miteinander in Konflikt stehen, oder ein bestehendes Programm, das durch eine frühere Verschiebung im selben Ablegevorgang in eine Überlappung gedrückt wird. Es gibt keinen separaten Codepfad für eine dieser Situationen – jeder Fall reduziert sich auf „Untersuche die Lücke zwischen benachbarten Programmen und wende die Regel an.“

2. Sechs Sekunden, nicht fünf. MediaLive erzwingt einen Mindestabstand von 5 Sekunden zwischen Planungsaktionen; die Planung von zwei Eingangsumschaltungen im Abstand von 4,9 Sekunden führt zu einer Ablehnung der Bereitstellung. Das System erzwingt 6 Sekunden – eine Ein-Sekunden-Sicherheitsspanne für die Takt-Drift zwischen der Uhr des Backends und der von AWS. Das Senden einer Aktion bei genau 5.000 Sekunden, wenn die Uhr des Encoders diese als 4.997 Sekunden liest, führt zu intermittierenden Ablehnungen, die wie Netzwerkfehler aussehen und sich wie nicht reproduzierbare Bugs anfühlen. Die zusätzliche Sekunde wandelt einen intermittierenden Fehlermodus in einen um, der einfach nie ausgelöst wird.

Dies geht mit einem bewussten Kompromiss einher: Eine 6-Sekunden-Untergrenze bedeutet, dass kleine Lücken von 3 oder 4 Sekunden, die direkt aufeinanderfolgen, auf null geschlossen werden, anstatt erhalten zu bleiben. Dieser Kompromiss wurde bewusst akzeptiert – direkt aufeinanderfolgende Übergänge sind auf MediaLive sauber, und eine sichtbare 3-Sekunden-Lücke wirkt auf Zuschauer ohnehin oft wie eine Störung.

3. Die Memoisierung der Originalzeit macht Kaskaden sicher. Ein einzelnes Ablegen kann eine Kette von Verschiebungen auslösen – Programm A verschiebt B, B verschiebt C, C verschiebt D. Der Bereinigungsaufruf an MediaLive muss die ursprüngliche bereitgestellte Zeit jedes Programms ansprechen, nicht seine kaskadiert-verschobene Zeit; die Verwendung der falschen Zeit führt dazu, dass MediaLive mit „no action found“ antwortet und die Bereinigung stillschweigend fehlschlägt. Der Durchlauf verwaltet eine Map von programId → {oldStartTime, oldEndTime}, die bei der ersten Berührung jedes Programms erfasst wird. Spätere Kaskaden-Verschiebungen aktualisieren nur die In-Memory-Timeline; die memoisierten Originale bleiben unberührt, und die Bereinigung verwendet immer genau das, was MediaLive tatsächlich verzeichnet hat.
Diagramm 2 · Ein Kaskaden-Beispiel
 

4. Vergangenheits-Schutz, in zwei separaten Phasen durchgesetzt. Bearbeitungen in der Vergangenheit werden bewusst zweimal blockiert:

• Phase 0, bevor der Snap-Walk läuft: Jedes neue Programm mit einer Startzeit, die früher als „jetzt“ ist, lehnt den gesamten Stapel sofort mit einem klaren Fehler ab. Der Snap-Walk läuft niemals gegen eine unmögliche Eingabe.
• Phase 4, nach dem Snap-Walk: Zwei unterschiedliche Unterfälle werden anders behandelt. Ein neues Programm, das der Snap versehentlich in die Vergangenheit gezogen hat (selten, aber an Takt-Grenzen der Anfragezeit möglich), wird stillschweigend auf seine ursprüngliche Zeit vor dem Snap zurückgesetzt – die Absicht des Operators bleibt erhalten, und der Snap wird einfach nicht angewendet. Ein bestehendes Programm, das eine Verschiebung in die Vergangenheit drücken würde, lehnt stattdessen den gesamten Stapel ab – das Berühren eines bereits angelaufenen Programms wird vom System niemals stillschweigend hingenommen.

5. Ein Lambda-zuerst, Datenbank-zweitens Schreibvertrag. Wenn ein Snap ein Programm verschiebt, das bereits auf MediaLive bereitgestellt wurde, sind MongoDB und MediaLive kurzzeitig nicht synchron, und die Reihenfolge der Abstimmung ist wichtig. Der Vertrag: Lambda zuerst, MongoDB zweitens. Das Backend ruft DELETE_PROGRAM auf Lambda mit den ursprünglichen Zeiten des Programms auf; falls ein Aufruf fehlschlägt, wirft das Backend einen Fehler, bevor eine Datenbankänderung stattfindet. Erst wenn jeder Löschaufruf erfolgreich ist, aktualisiert ein einziges bulkWrite MongoDB mit den neuen Zeiten und setzt isDeployed: false zurück.

Dies erzeugt eine saubere Invariante: Wenn MongoDB ein Programm zu einer neuen Zeit anzeigt, hat MediaLive diese Verschiebung bereits akzeptiert. Wenn der Operator stattdessen einen Fehler sieht, wurde keines der Systeme berührt. Es gibt keinen möglichen Zustand, in dem MongoDB und MediaLive stillschweigend über die Zeit eines Programms uneinig sind.

6. Der Reset-Tag hat sein eigenes dediziertes Sicherheitsnetz. Der „Reset-Tag“ löscht jedes Programm auf einem Kanal für einen bestimmten Kalendertag – die zerstörerischste Operation im System – daher verfügt er über zwei spezifische Schutzmaßnahmen.

• Ein 2-Minuten-Puffer (SAFETY_BUFFER_MS = 120000) nimmt jedes Programm aus, das innerhalb der nächsten zwei Minuten beginnt, und gibt der Live-Wiedergabe ein Gnadenfenster, sodass ein Reset niemals mit einem Programm konkurrieren kann, das kurz vor der Ausstrahlung steht. 
• Übernahmeerhaltung schließt Programme aus, die am Vortag begonnen haben, aber in den heutigen Tag hineinreichen – diese gehören zum gestrigen, nicht zum heutigen Zeitplan. 

Eine elegante Fallback-Lösung ist ebenfalls verfügbar: Wenn ein Kanal überhaupt nie auf MediaLive bereitgestellt wurde, gibt Lambda eine bestimmte Fehlerzeichenfolge zurück, die das Backend versteht, als no_infrastructure protokolliert und dann eine reine MongoDB-Soft-Deletion durchführt. Der Reset ist weiterhin erfolgreich; der AWS-Schritt wird einfach zu einem No-Op.

Warum diese Kombination von Designentscheidungen

Was noch beobachtet wird

Ehrliche Ingenieurskunst bedeutet, die Lücken zu benennen, die offen bleiben, nicht nur jene, die gelöst wurden.

• Gleichzeitige Bearbeitungen auf demselben Kanal. Wenn zwei Operatoren innerhalb weniger hundert Millisekunden gleichzeitig „Deploy“ auf demselben Kanal klicken, laden beide denselben Snapshot, beide führen den Snap-Walk unabhängig voneinander aus und beide schreiben in MongoDB. Es gibt heute keine kanalspezifische Sperre oder optimistische Versionsprüfung. Die derzeitige Abhilfemaßnahme ist operativ – ein Operator besitzt jeweils einen Kanal – während die technische Lösung, ein Versionsfeld im Kanaldokument, das zur Schreibzeit geprüft wird, auf der Roadmap steht.
• Kein In-UI-Feedback darüber, was gesnappt wurde. Wenn der Walk ein Programm um drei Sekunden verschiebt, aktualisiert sich die Ansicht des Operators auf den korrigierten Zustand, zeigt aber noch nicht an, was sich bewegt hat und warum. Die Daten sind bereits in der Antwortnutzlast vorhanden; ein Toast, eine Seitenleiste oder eine Diff-Ansicht ist für die nächste Iteration der Scheduler-UI geplant.

Ergebnisse

• Operatoren können ein Programm überall auf der Timeline ablegen, und das System macht den resultierenden Zeitplan in einem deterministischen Durchlauf rechtsgültig – keine Konflikt-Modals, keine Fehlermeldungen, keine manuellen Snap-Berechnungen.
• Ein einziger Vier-Regel-Algorithmus deckt jeden Fall ab – neu gegen neu, neu gegen bestehend und kaskadierende Verschiebungen über Tagesgrenzen hinweg – ohne einen davon als Sonderfall zu behandeln.
• Programme über Mitternacht und DST-Übergänge laufen durch dieselbe Zeitbereichs-Überlappungsabfrage wie jeder andere Fall; es gibt keinen separaten „Mitternachts-Codepfad“ zu pflegen.
• Der Reset-Tag kann ein Live-Programm nicht versehentlich aus der Ausstrahlung nehmen – der 2-Minuten-Puffer und die Übernahmeerhaltung gelten für jeden Kanal, jederzeit.
• Der Lambda-zuerst / Datenbank-zweitens Vertrag macht eine stillschweigende Zeitplan-Drift unmöglich: MongoDB und MediaLive stimmen garantiert überein, oder der Operator sieht einen expliziten Fehler.

• MIN_NEIGHBOUR_GAP_MS ist der einzige einstellbare Parameter. Jede Sicherheitsspanne, jede Snap-Regel und jedes Überlappungsfenster verweist darauf, sodass die Anpassung der plattformseitigen Definition von „rechtsgültig“ eine Ein-Zeilen-Änderung ist.

   

Abschließende Gedanken

Das Interessanteste an diesem System ist nicht eine einzelne Regel – es ist, wie wenige Regeln benötigt wurden. Vier Bedingungen für einen Lückenwert, angewendet in einem einzigen Vorwärtsdurchlauf, decken jeden Konflikt ab, den ein Operator erzeugen kann, einschließlich mehrstufiger Kaskaden über Mitternachtsgrenzen hinweg. Das ist ein bewusstes Designergebnis: Die Komplexität wurde darauf verlagert, die Regeln einmal richtig zu definieren, anstatt eine ständig wachsende Liste von Sonderfällen zu behandeln.

Die übergreifende Lektion geht über Planungssoftware hinaus: Wenn ein System harte externe Einschränkungen hat – den Mindestabstand eines Encoders, die Konsistenzgarantien einer Datenbank, eine Live-Übertragung, die nicht rückgängig gemacht werden kann –, ist der sicherste Ort, diese Einschränkungen durchzusetzen, in einer kleinen Anzahl deterministischer Regeln, die konsistent angewendet werden, nicht in ad-hoc-Behandlungen, die über die Codebasis verstreut sind. Und wenn zwei führende Systeme (hier, MongoDB und MediaLive) synchron bleiben müssen, ist die Reihenfolge der Schreibvorgänge so zu gestalten, dass ein Fehler sie immer in einem bekannten, übereinstimmenden Zustand hinterlässt, die zusätzliche Latenz wert, die es kostet.
 

Über MicrocosmWorks

Bei MicrocosmWorks entwickeln wir produktionsreife Software für Organisationen, die komplexe technische Probleme lösen.

Unsere Expertise umfasst AI-Anwendungen, SaaS-Plattformen, Unternehmenssoftware, Cloud-Native-Systeme, Medientechnologie und kundenspezifische Backend-Architektur.

Durch unseren Engineering-Blog teilen wir praktische Erkenntnisse, die wir beim Entwerfen und Betreiben von realen Produktionssystemen gewonnen haben.

Weiterlesen

Wenn Ihnen dieser Artikel gefallen hat, könnten Sie auch folgende Themen nützlich finden:

• Skalierbare SaaS-Architekturen aufbauen
• Cloud-Native Infrastruktur
• Enterprise-Videoverarbeitung mit FFmpeg