meine mAirList-Version: 6.3.14 Home Studio
Windows 10
Bei einer Übergabe klappte aus unbekanntem Grund die erste Verbindung zum Server nicht.
Der 2. Verbindungsversuch war erfolgreich, erfolgte aber erst nach 5 Sekunden, weil das so eingestellt ist.
Systemprotokoll:
27.11.2021 22:01:00 Information Encoder verbindet mit s1.radio-xxx:80/live2
27.11.2021 22:01:05 Information Encoder-Verbindung zu s1.radio-xxx:80/live2 hergestellt
Wir haben das intern diskutiert. Nach unserer Einschätzung dürfte das von dir markierte Feld nicht die Ursache sein.
Schritt für Schritt:
Die 5-sekündige Zeitdifferenz im Systemprotokoll sehen wir serverseitig.
Der angestreamte Server hat einfach so lange gebraucht, um dir zu antworten - oder es lag auf dem Weg hin und zurück oder oder.
“Verbindungsversuche und -tests”: Die Verbindung wird intern (!) regelmäßig überprüft. Allerdings sollte, wenn es hier zu einem Fehler kommt, vorher schon ein BASS-Fehler gemeldet werden. BASS würde vermutlich vor Ablauf des 5-Sekunden-Zeitfensters alarmieren.
Falls nicht, greift mAirList ein und erkennt eigenständig einen Verbindungsfehler.
(2a) Insofern ist es beinahe schon Glück, dass mAirList nicht einen Netzwerk-Verbindungs-Timeout ausgelöst hat, der ebenfalls auf 5 Sekunden steht:
Soll heißen: Hätte dich die Serverantwort nur Sekundenbruchteile später erreicht, hätte mAirList einen Verbindungs-Timeout erkannt und nach 10 Sekunden automatisch einen neuen Verbindungsaufbau versucht.
Ich tippe auf “historisch gewachsen” in der mAirList-Entwicklungsgeschichte.
Nun haben natürlich auch Anwender über mAirList-Generationen hinweg eigene Erfahrungen gemacht und dort individuelle Werte eingetragen; vielleicht können wir uns hier austauschen.
Es kann natürlich auch sein, dass wir den ein oder anderen Wert in der Erstinstallation als Kompromiss aus Erfahrungswerten und “es muss ja was drinstehen” sowie Rücksichtnahme auf Abwärtskompatibilität eingetragen haben.
Beispiele:
Beim Auto-Cue hat Torben einen (zugegebenermaßen) sehr niedrigen Wert von -200 dB als “something about silence” definiert, auch wenn TSD diesen Wet physikalisch widerlegen konnte und ich im Thread zum Erfahrungsaustausch aufgerufen habe. Dennoch, und das ist der Gag, schadet er beim ersten Einsatz von mAirList auch nicht.
Mir wurde neulich mitgeteilt, dass die Normalisierung in v6.3 ja -1 dBTP ein “mAirList-Default-Wert” sei und daher als Vorgabe genutzt würde.
Richtig ist: In einer Neuinstallation steht dieser Wert drin, wo vorher einzig 0 dBFS stand. Daraus jedoch abzuleiten, dass das von uns empfohlen wird, greift zu weit.
Es stehen vielmehr drei Optionen zur Verfügung, aus denen man wählen kann, und die Werte lassen sich zudem verändern (nicht in allen Ländern sind -1 dBTP der erlaubte headroom, es können auch mal -3 dBTP sein).
Nehme ich jetzt EBU R 128 (original) oder EBU R 128 s2? Mit welchen Werten?
Der Anwender bzw. Radiobetreiber bestimmt die Werte. Wenn ich einen Beitrag bei einem freien Journalisten in Auftrag gebe, dann mache ich auch eine Vorgabe, wie das Ergebnis rein technisch bei mir anzukommen hat.
Nicht wir von mAirList sagen dem Radiomacher oder dem “Heimstudio”, wie und mit welchen Werten er mAirList zu betreiben hat. Aber wir liefern ein umgehend lauffähiges Produkt aus.
Ich persönlich rate von der Peak-Normalisierung grundsätzlich ab, weil ich sie schon seit Jahren für den falschen Weg halte (man kann das seit ewig hier im Forum nachlesen, und da habe ich noch nicht für mAirList gearbeitet). Es gibt aber viele professionelle Kunden, die das nutzen, weil dahinter ohnehin ein professionelles Soundprocessing steht.
Ja, alle Werte lassen sich verändern.
Eine 0 kann gegebenenfalls als “gar nicht” interprtiert werden, da muss ich Torben als Informatiker noch mal fragen.
Welcher Wert ist sinnhaft?
Ich werfe diese Frage zum Erfahrungsaustausch ins Forum. Wie macht ihr das?
Hier fehlt noch das Feedback, da es um den Server geht, den ich administriere, soll natürlich hier natürlich auch für andere eine mögöiche Lösung dabei raus kommen.
Wir hatten tatsächlich ein Problem mit der Firewall auf unserem Virtualisierungsserver. Der warf ausserdem Kernelfehlermeldungen. Da gab es wohl einen Bug.
Nach dem Update und einem Neustart der ganzen Maschine funktioniert jetzt zwar die Firewall wieder richtig aber bei @Moni und wie es aussieht, im Moment nur bei ihr, tritt immer noch ein ähnliches Phänomen auf.
Die Zeit ist kürzer geworden es sind nur noch 3-4 Sekunden, bei anderen geht das aber instant.
Wir haben verschiedene Ports ausprobiert, ich hatte schon Netzanbieter die keinen Stream in Richtung eines Port 80 zugelassen haben, bei port 8000 ist es aber genau gleich, das ist also auch nicht unser Problem.
Aktuell gibt es also noch keine Lösung und mir fehlt da auch ein wenig der Ansatz.
Moni hat einen DSL Anschluss, wenn ich das noch richtig im Kopf habe, also das typische Latenzprobelm, was wir aus dem Kabelnetz kennen, ist es auch nicht. Dagegen spricht auch, dass es keinen Buffer Overflow gibt, wenn dann die Verbindung erst einmal steht funktioniert alles.
Siehste: Hilft doch, wenn man das Forum ordentlich nutzt, wo ich das hier so runter schreibe, habe ich gerade eine Idee, was es sein könnte.
I’ll be back.
EDIT: Nein, die Idee kann ich wieder verwerfen.
Es macht einen Untschied, ob man im Encoder den Server mit oder ohne http davor einträgt. Oben im Screenshot sieht man aber, dass es ohne http eingetragen ist, was so passen müsste.
Falls noch jemand eine Idee hat, was wir prüfen können, gerne her damit. Wir haben zwar ein Woraround etabliert aber das behandelt nicht die Ursache sondern nur das Symptom.
Besteht die Möglichkeit, dass @Moni euren Server anpingt und ihr so mal die Lauf- bzw. Antwortzeiten ermittelt oder bringt das den laufenden Betrieb durcheinander?
Schwierig. Ich kenne dich ja als erfahrenen IT’ler, daher vermuute ich, dass du die klassischen Standards alle schon durch hast. Und einige “deiner” Morderatoren nutzen ja mAirList mit unterschiedlicher Begeisterung, da werdet ihr euch untereinander ja auch schon ausgetauscht haben.
Wenn du oder dein Team reproduzierbare!) Anzeichen dafür findet, dass es irgendwie mit mAirList zu tun haben könnte, freuen wir uns über Hinweise.
definiert, auch wenn TSD diesen Wet physikalisch widerlegen konnte und ich im Thread zum Erfahrungsaustausch aufgerufen habe. Dennoch, und das ist der Gag, schadet er beim ersten Einsatz von mAirList auch nicht.