Eigener Zeitserver

Deutsch / German Feature-Requests
1

Guten Tag,
Wir beschäftigen uns gerade mit dem Thema Timing bis zum Hörer. Eines Vorweg, reden wir hier vom Hobby Bereich.
Folgende Ausgangssituation liegt vor:

Mairlist auf Cloud Server 24h Rotation.
Ausspielung auf Liquidsoap (externer Server)
Moderatoren mit mAirlist verbinden direkt auf Liquidsoap Harbor

Ich weiß auch das das Thema Latenz und Puffer im Webradiobereich fast unberechenbar ist, jedoch versuchen wir gerade die gröbste Latenz etwas zu minimieren.
Dabei sind wir im Schnitt ca 1,5 Min also 90 Sekunden im Versatz wenn wir zur pünktlichen Stunde XX beispielsweise einen Gong senden. Dieser kommt in aller Regel um XX:X1:30 beim Hörer an.

Nun müssten wir Theoretisch, um etwa beim Hörer irgendwie pünktlich ankommen zu können den Gong bereits um XX:58:30 spielen.

Zwar kann ich die interne Uhr dem entsprechend anpassen, jedoch würde ich das auch gerne bei allen anderen mAirlist Moderatoren gleich umsetzen wofür man, ohne jetzt den ganzen Windowsrechner umzustellen, mAirlist auf einen seperaten Zeitserver einstellen würde.
Der Zeitserver selbst würde dann der errechneten Latenz angepasst werden können.

Für nicht mAirlist Moderatoren könnte man seperate Uhren Programme verwenden die dann auf den Manuellen zeitserver eingestellt sind.

Wäre das generell möglich?

BTW. Ich weiß auch das die Latenz durch Encoder Transcoder etc und verschiedenen Player beim Ausspielenden Gerät teils unberechenbar ist. Sei es eine App oder Webplayer oder VLC und so weiter.
Dennoch bin ich der Meinung das ich zumindest die Zeit die das Signal von mAirlist bis zum erreichen des Puffers des Ausspielgerätes weitestgehend eliminieren kann.
Auch ist mir bewusst das ein Webradio nicht dazu geeignet ist seine Uhr danach zu stellen. :slight_smile:

Danke trotzdem schon mal

2

Und was genau davon ist jetzt das eigentliche feature request an die Software mAirList?

3

Die möglichkeit einen Programminternen Zeitserver einstellen zu können.
Also keinen Systemweiten in Windows sondern in mAirlist seperat. :wink:

4

Hallo Tom,

brauchst Du da wirklich einen eigenen Zeitserver? Du kannst, wie hier beschrieben, ein Offset zwischen mAirList- und Systemzeit eingeben, das ist doch was.

Ich rate trotzdem davon ab, weil Du die Latenz sowieso nicht genau weißt und der Gong beim Hörer dann in den allermeisten Fällen ja doch falsch ankommt. Da habe ich (als Hörer) lieber gar kein Zeitzeichen als ein irgendwie ungenaues.

Ich finde außerdem, mAirList sollte Radioautomation bzw. -ausspielsoftware bleiben und nicht zur eierlegenden usw. werden.

In der Hoffnung, niemanden belehrt zu haben,

TSD

5

@Tondose

Da bin ich nur teilweise bei dir.
Timings gehören nunmal auch in eine Radio Software wie Mairlist um unter anderem auch verschiedene Studios zu synchronisieren.
Was liege da näher als einen eigenen Zeit server aufzusetzen und mAirlist darauf konfigurieren zu können?
Ich sagte ja nicht das mAirlist diesen Server betreiben soll. Nur das ich mAirlist darauf konfigurieren könnte. Systemintern versteht sich. :wink:

6

Ja, so rum wird’s für mich eher ein Schuh. Jetzt bin ich aber mal ganz pragmatisch und sage meinen Moderatoren, daß sie auf 58'30" timen sollen. Das schult auch das Kopfrechnen ungemein. :slightly_smiling_face:

@UliNobbe: Tom möchte, daß die mAirList-Zeit mit einem externen ntp-Server synchronisierbar wird. Den tatsächlichen Vorteil daran habe ich auch noch nicht so ganz verstanden.

Synchronisierte Grüße

TSD

Edit: Oh, jetzt ist Ulis Antwort wieder wech!

7

Zeitserver und ihr pnedant, der Zeit-Clients (um den es hier eigentlich geht) sind ein deutlich komplexeres Thema, als es zunächst den Anschein hat. Du kannst nämlich nicht einfach stumpf mal eben 1:30 min Offset einstellen. Jeder halbwegs vernünftig implementierte NTP-Client würde diesesn Sprung verweigern, sofern nicht vom Administrator/ root angewiesen. Üblicherweise redet man von Korrekturen im Sekunden oder Milisekundenbereich. Ein so großer Sprung, im Minutenbereich, müsste also über einen längeren Zeitraum angeglichen werden.
Dementspechend hat das auch nichts mit Radioautomation zu tun und folglich, IMHO kein Feature für mAirlist.

Von den technischen Aspekten rund um das komplexe Thema Zeitsynchronisation, mal ganz abgesehen, ist das bei http basierten Streaming vergebliche Liebesmühe. Nicht einmal im digitlaen Rundfunk (DAB oder DVB) hat man es hin bekommen, mit einheitlichen Buffer-größen zu arbeiten, was man bei der Fußball EM/WM ja immer deutlich merkt. Mit http als Basis ist das noch mal einen deutlichen Schritt unberechenbarer. Je nach dem ob mein Handy gerade 4G oder Edge hat, wird der Puffer dynamisch angepasst.

Wie willst Du also die notwendige Latenz überhaupt sinnvoll messen, wenn Du die wichtigste Komponente, nämlich den Player des Hörers, gar nicht kennst?
Selbst wenn man so weit gehen würde, dass man ein komplett anderes Streamingprotokoll verwendet, hast Du im Internet immer deutlich schwankende Latenzen, die genau so wenig berechenbar sind, weil sie für jeden Teilnehmer anders sind. Mit einem UDP Multicast gekopplet an einen Time-Code, wie es etwa Apple-Airplay oder Sonos und co. verwenden, könnte man das Signal synchronisieren aber auf die Puffer hättest Du immer noch, so gut wie keinen Einfluss. Diese Lautsprecher schaffen es zwar Synchron zu bleiben, das ist aber auch keine Echtzeitübertragung, die “einigen” sich nur auf den kleinsten gemeinsamen nenner. Der kann aber immer noch, ziwschen ein paar Sekunden und ein paar Minuten großen sein (theoretisch).

IP Basierend kann man zur Zeit einfach keinen analogen Rundfunk nachbauen, jedenfalls nicht ohne erheblichen finanziellen Einsatz um einige hoch begabte Enwtickler zu bezahlen.
Übrigens selbst auf UKW bekommen es einige Stationen (Privatradios in Niedresachsen) nicht hin, ein synchrones Programm ausziliefern.

1 Like
8

Ich bleibe dabei, daß auch ein in etwa genaues Zeitsignal sinnlos ist. Entweder pünktlich oder gar nicht. (Meine Meinung, keine Belehrung!)

Aus dem Nähkästlein: Selbst das UKW-Programm hr-Info hat etwa 2 Sekunden Latenz gegenüber dem Pultausgang. Warum? Weil es jede Menge Füllsender mit Leistungen im zweistelligen Wattbereich gibt, die über Satellit, also verzögert, versorgt werden. Damit man beim automatischen Wechsel von einer auf die andere Frequenz dann keinen Modulationssprung erfährt, wird eben auch das „direkte“ UKW-Signal verzögert ausgestrahlt. (Im Prinzip also das, was @shorty.xs den „kleinsten gemeinamen Nenner“ nennt.)

Synchrone Grüße

TSD

1 Like
9

“Von den technischen Aspekten rund um das komplexe Thema Zeitsynchronisation, mal ganz abgesehen, ist das bei http basierten Streaming vergebliche Liebesmühe. Nicht einmal im digitlaen Rundfunk (DAB oder DVB) hat man es hin bekommen, mit einheitlichen Buffer-größen zu arbeiten, was man bei der Fußball EM/WM ja immer deutlich merkt. Mit http als Basis ist das noch mal einen deutlichen Schritt unberechenbarer. Je nach dem ob mein Handy gerade 4G oder Edge hat, wird der Puffer dynamisch angepasst.”

Wie schon anfangs geschrieben ist es mir vollkommen klar das man solche Variablen niemals komplett in dem griff bekommt.

" Ja, so rum wird’s für mich eher ein Schuh. Jetzt bin ich aber mal ganz pragmatisch und sage meinen Moderatoren, daß sie auf 58'30" timen sollen. Das schult auch das Kopfrechnen ungemein. :slightly_smiling_face: "

Prinzipiell ja aaaaber in der Praxis sieht das dann doch anders aus. Glaub mir auch diese Mühen das allen immer und immer wieder zu sagen sind vollkommen nutzlos :wink: woher ich das weiß? Eigene Erfahrung

"
Tom möchte, daß die mAirList-Zeit mit einem externen ntp-Server synchronisierbar wird. Den tatsächlichen Vorteil daran habe ich auch noch nicht so ganz verstanden."

Das sich alle Studios zur errechneten oder meinetwegen geschätzten Latenz dennoch pünktlich übergeben bzw der Wechsel mit der 24h Rotation zum Stundenwechsel passt.

" Nicht einmal im digitlaen Rundfunk (DAB oder DVB) hat man es hin bekommen, mit einheitlichen Buffer-größen zu arbeiten, was man bei der Fußball EM/WM ja immer deutlich merkt."
Das liegt einzig und allein an den VERSCHIEDENEN Übertragungswegen sei es teresstrisch, Kabel, IP oder Sat Übertragung.
Wir haben nur IP also hinkt der Vergleich. :wink:

" Wie willst Du also die notwendige Latenz überhaupt sinnvoll messen, wenn Du die wichtigste Komponente, nämlich den Player des Hörers, gar nicht kennst?"

Gar nicht und das hab ich auch im Anfangspost so geschrieben das ich die Puffer der Player nicht beeinflussen kann. Aber zumindest kann ich anhand direkter Beobachtung in LS feststellen anhand der Meta wann eine Änderung ankommt. Es geht mir einzig und allein um diese recht konstante Latenz zwischen zweier Server die Netto etwa noch 50 Sekunden beträgt. Warum auch immer :thinking:

10

Oje, ist das Programm so schlimm …?

(Späßle gemacht)

TSD

11

Spaß beiseite: Ich glaube, ich habe verstanden: Es geht darum, daß die einzelnen Sendungen (relativ) pünktlich anfangen bzw. enden und keiner dem anderen in die Absage lallt oder Sendepausen entstehen. Die absolute Zeit (-differenz) beim Hörer ist eher nachrangig.

Pünktliche Grüße

TSD