Automatischer Playerstart nach bestätigter Encoder-Verbindung

Ja, ich weiß, vergleichbare Ansätze gab es schon.
Ich suche es noch schlanker und flexibler.

Pflichtenheft

  • Kurzbeschreibung: Nach Aufruf wartet das Script auf die bestätigte (!) Encoder-Verbindung und startet erst dann das erste Element; ganz gleich, in welchem Player es gerade liegt (PlayerState=NEXT).

  • Kein Hintergrundscript, sondern einmalig, zu starten als Fernsteuerkommando
    RUNSCRIPT <C:\Path\to\Script.mls>.
    Sobald der Job ordnungsgemäß erledigt ist, wird das Script im laufenden Betrieb nicht mehr benötigt.

  • Ein spezieller Encoder wird nach “Encoder-Verbindung herstellen” gezielt abgefragt, ob er nach connecting dann auch wirklich connected ist.

    • Ableitung: Wie bereits an anderer Stelle beschrieben, kann man auch alle aktiven ( :white_check_mark:) Verbindungen abfragen und das zur Bedingung machen. Das hängt letztlich vom jeweiligen Anwender und der Zahl seiner gleichzeitig benötigten Verbindungen ab.
  • Daraufhin wird automatisch ein Player gestartet, und zwar nicht statisch (PLAYER 1-1 START), sondern eben jener, der gerade “dran” ist, also im PlayerState=NEXT steht.

Das war’s auch schon.

Einen netten Ansatz hierzu gab es bereits am 24. Juli 2019. Nur eben mit dem absoluten Player und einem Abfrage-Intervall.

Mittlerweile sind wir aber bei OnEncoderConnectionStateChange angekommen und können die Stati ecsConnected, ecsDisconnected sowie, tadaa!, ecsConnecting abfragen.

Da macht die Sache doch gleich sehr viel mehr Spaß, oder?

Geht so was mit einem (nicht wörtlich nehmen!) Dreizeiler?

Vorgeschichte

Ich hatte das auch schon mal an anderer Stelle grob angedacht:

Dem war tatsächlich so, denn die Antwort fiel positiv aus:

… mit dem Link auf das (von mir seit heute wieder entstaubte) Script vom 31. Mai 2021.

Und warum das alles?

Dieses “Übergabe”-Gedöns zwischen Webradio-Moderatoren möchte ich (für mich, Typ “faule Socke”, und vielleicht auch meine mAirList-Kollegen) optimieren.

Der angesagte Countdown stimmt manchmal nicht (“15…9…7…3 - LOS”), insbesondere bei einer bestimmten Software, deren Name mir gerade rein zufällig :upside_down_face: entfallen ist - und selbst wenn man noch so reaktionsschnell ist, grätscht einem dann mitunter noch die Automation des Streamanbieters mit einem ekligen Fade dazwischen.
Cold ends versaut das ebenso wie geile Auftakte.

Wenn ich jetzt im Encoder die Sekunden zwischen Verbindungsversuchen auf 1 setze und im Countdown auf 3 das Script starte, weiß ich mit Beginn des ersten Elements, dass die Verbindung steht, alles läuft und ich kann unbeschwert anmoderieren.

Das ist alles.
Wer spielt mit?

Es geht vor allen Dingen nicht als

Die Prozedur OnEncoderConnectionStateChange muß ja sozusagen wachsam sein, was mit der Verbindung passiert. Ich weiß gar nicht, was gegen Hintergrundskripte einzuwenden sein soll – keine Angst, Euer Rechner geht davon nicht in die Knie.

Das würde hinzukriegen sein.

Da kannst du mal sehen, wo mein Nachholbedarf liegt (seufz).
Ich hatte die Idee “wenn das Script seinen Job getan hat, kann es weg”.

Begründung: Im Hintergrund brauche ich ja keinen watchdog, der mir bei einer ggf. wiederhergestellten Verbindung (kurzer dropout in der Sendung?) dann einen Titel startet, den ich zu dem Zeitpunkt gar nicht spielen möchte.

Diese Bremse muss wiederum drin sein.
Kannst du die Problematik nachvollziehen?

Ja. Die Bremse kann man aber einbauen.

1 Like