Ich betreibe mAirList 6.3 Professional Studio auf einem Windows Server 2019 (Dedicated) bei Hetzner. Die Test-Lizenz die ich für den Aufbau benutze ist korrekt aktiviert und laut Hersteller voll kompatibel mit Serverbetrieb.
Das Problem: Der Encoder bleibt permanent im Status “wird gestoppt” und lässt sich weder manuell starten noch automatisch beim Laden der Konfiguration aktivieren.
Audiowiedergabe von der Datenbank funktioniert über RDP-Sitzung einwandfrei – lokale Tests mit Playern zeigen, dass das Audiosignal ausgegeben wird. Dennoch wird keine Verbindung aufgebaut und es erscheint kein Logeintrag zum Encoder-Start.
Bisher geprüft:
Audio-Devices in mAirList korrekt zugewiesen (als Aufnahmequelle u. W. auch für Encoder konfiguriert)
Keine Firewall- oder Portblockade auf der Streaming-IP/Port oder gar Mairlist.
Encoder-Streams in der Konfiguration korrekt hinterlegt (Icecast)
RDP Audioumleitung aktiv – auch getestet mit deaktivierter Umleitung
Fragen:
Muss unter Windows Server zwingend ein „virtuelles Audiointerface“ (z. B. VB-Audio) vorhanden sein, damit der Encoder intern ein Signal erkennt? Weil diese Probleme habe ich auf einen anderen Server mit eigener Mairlist Lizenz so nicht. Server kommt auch von Hetzner.
Gibt es bekannte Einschränkungen im Encoderbetrieb unter RDP-Sessions?
Ich bin für jede technische Analyseidee oder Hinweise zur Fehlerquelle dankbar. Habt Ihr Ideen wie ich vorgehen könnte?
Auch die zwei Tipps führen dazu das der Encoder leider nicht nicht startet. Hinzu kommt das nun beim Starten des Encoders ein Fehler kommt mit der Bezeichnung: “BASS_WASAPI_Init: BASS error 46”. Laut der Übersetzung heisst das so wie das gewünschte WASAPI-Gerät entweder nicht verfügbar, nicht aktiv, oder blockiert (häufig z.B. aufgrund von fehlendem physikalischem Ausgang auf Server-Systemen, deaktivierten Audiogeräten im Windows-Manager oder Remote-Desktop-Konflikt). Aber auch hier habe ich alles aktiviert.
Mit diesen Einstellungen funktioniert Mairlist auf einen anderen Windows Server von Hetzner. Kopiere ich für den weiteren Windows Server die Einstellungen bleibt der Encoder dort weiterhin “auf gestoppt” ich finde nirgends eine Lösungsansatz.
Sobald du die Remote Desktop Verbindung beendest, wird auch dieses virtuelle Audiogerät deaktiviert.
Das könnte fast nur möglich sein, wenn es ein dedizierter Server ist. Also das gesamte Gerät (PC) genutzt und wird und keine weiteren Virtuellen Maschinen drauf laufen. Aber wozu sollte man in einem Rechenzentrum Audiohardware verwenden?
Auch diese Einstellung auf dem neuen Windows Server funktionieren leider nicht. Beim bisherigen Server funktionieren die Einstellung wie oben. Sind beides Dedicated Server.
Zitat:
Das liegt an dem Remote Audio.
Sobald du die Remote Desktop Verbindung beendest, wird auch dieses virtuelle Audiogerät deaktiviert.
Auf dem bisherigen Server funktioniert auch der Encoder und der Stream sobald vom Server runter geht.
Dann versuche mal das Remote Audio auch zu deaktivieren bevor du dich auf den Server verbindest. Das findest du in den Optionen der RD Verbindung auf deinem PC.
Verbinden…
Danach am besten mAirList neu starten. (Auch alle anderen Dinge wie dbserv.bat oder Autoimpoter) Es darf jetzt keine Fehlermeldung kommen die ein Audiogerät erwartet. Wenn doch hast du noch etwas eingestellt das da nicht rein gehört.
Warum das geht können wir dir nicht erklären. Hast du den selbst eingerichtet?
Auch diese Einstellung auf dem neuen Windows Server funktionieren leider nicht. Beim bisherigen Server funktionieren die Einstellung wie oben. Sind beides Dedicated Server.
Zitat:
Das liegt an dem Remote Audio.
Sobald du die Remote Desktop Verbindung beendest, wird auch dieses virtuelle Audiogerät deaktiviert.
Auf dem bisherigen Server funktioniert auch der Encoder und der Stream sobald vom Server runter geht.
Bekannter meinte ich das der Windows Server ein virtuelles Audiointerface (z.B. VB-Audio) benötigt, damit der Encoder intern ein Audiosignal erkennt. Fehlt dieses, bleibt der Encoder oft im Status “wird gestoppt” und startet nicht, obwohl andere Audiowiedergaben funktionieren. Das wurde in Community-Foren mehrfach als Ursache genannt, speziell bei Windows Server 2019 in RDP-Umgebungen.
Auch das hilft nicht, wobei ich in beiden Fällen Windows Server 2022 installiert habe.
Sowas hatte ich schon vermutet und das wäre mein nächster Ansatz gewesen. Von solchen Konstellationen und Basteleien nehme ich aber diskret Abstand.
Ja, es ist möglich über VB Audio etc… die Ton Signale über ein Netzwerk zu schicken. Aber das würde ich niemals auf einem öfftlich im Netz stehenden Server machen sondern nur ggf im eigenen LAN.
Was sagt denn das Status-Log? Da muss ja irgendwas drin stehen, wenn mAirList eine Fehlfunktion hat bzw. nicht so arbeiten kann, wie es möchte.
Und noch eine Frage: Wenn exakt diese Kombination auf einem anderen Server funktioniert, aber nicht auf diesem hier, dann spricht doch vieles dafür, dass es NICHT an mAirList liegt.
Für mAirList gilt das aus meiner eigenen Erfahrung definitiv nicht. Ich habe inzwischen seit WinServer 2016 schon etliche Hetzner- (und andere) Server mit mAirList eingerichtet und das ging bisher immer ohne Umwege über den Encoder.
Nächste Frage: Wird hier StereoTool oder ein anderes SoundProcessing-Tool genutzt?
Im Status-Log steht zu dem Thema nichts drin. Ich habe heute noch einmal den neuen Windows Server neu aufgesetzt, danach kommt dasselbe Problem.
Ich vermute das auch, das Mairlist das Problem nicht auslöst, wenn auch Hetzner Mitarbeiter meint das Mairlist offene Ports für Viren nutzt und das Programm nicht zu empfehlen sei.
Ja, es wird das empfohlende Stereo-Tool genutzt. Bei beiden Servern ist das der Fall.
Schwer vorstellbar.
In diesem Fall müsste Hetzner seine Strategie geändert haben.
Bei meinem vorigen Sender wurde genau diese Konstellation auf einem kleinen Hetzner-Server aufgesetzt, wobei Stefan dem Sender bei den ersten Schritten geholfen hat.
Ich hatte mehrfach Kontakt mit dem Hetzner-Support und in sehr freundlichen, teils vertrauten Gesprächen war klar, dass mAirList die für ein privates Webradio beste Konstellation sei.
Wenn aus dieser Ecke plötzlich Skepsis oder gar Misstrauen kommt, wäre das für mich neu.
Bislang war ich immer ein Hetzner-Befürworter, aber wenn ich nochmal technisch für einen Sender tätig würde und so eine Aussage bekäme, wäre Schluss mit lustig.
