Dropouts nach längerer Laufzeit auf dem Server

Archive mAirList 4.x (Deutsch)
1

Hallo!
Wir haben mAirList auf einem Windows Web Server 2008 R2 laufen.

Die Konfiguration des Servers:
CPU: Intel Celeron G530 @2,4GHz
4GB Ram
64Bit System

Virtuelle Soundkarte
Stream-Verteilung über Winamp mit Shoutcast.
Stream-Control zu Überwachung der Upstreams

mAirlist streamt auf einem extra Port mit geringer Priorität gegenüber den anderen Upstreams an Streamcontrol, das den Stream dann an Winamp mit Shoutcast weiterleitet.

Nach 2-3 Wochen merkt man zusehends, wie der Shoutcast immer mehr am buffern und knacken ist.
Das überträgt sich auch auf die anderen Upstreams. Nichts läuft mehr sauber.
Wenn man dann mAirList runterfährt und das System solo laufen lässt, ist alles wieder sauber.

Das war vor Installation des mAirList-Systems nicht.

Woran kann das liegen und welche Lösung gibt es?

2

Hmm, das ist interessant.
Ich beobachte auf unserem Server mit mAirList 3 ein ähnliches phänomen, habe das aber noch nicht so weit eingrenzen können.
Bei mir läuft es auf einem virtuellen Server ohne Soundkarte und Encodiert direkt. Der ausgehende Stream geht dann zu einem externen Shoutcast Server.
Irgendwann nimmt der Windows Server dann aber keine verbindungen mehr an oder reagiert darauf sehr langsam. Dann hört man auch diese Dropouts, also der Streamserver bekommt nicht genug Daten nach.

Neben mAirList läuft auf dem Server noch ein FTP Serverdienst, der allerdings nur zur Wartung gelegentlich mal benutzt wird.
Ausserdem ein Shoutcast 2, da der unter Windows auch ohne root/Admin Rechte auf Port 80 läuft. Bei dem ist mir aufgefallen, dass der beim starten schonmal 24 Network connections öffnet. Warum auch immer, der SC 1 ist da erheblich genügsamer.

Ich habe den Zeitraum noch nicht so ganz raus, in dem der Fehler auftritt. Meist bleibt mir dann nichts anderes als, den Server zu re-booten, denn da er keine Connections annimmt, komme ich auch remote nicht mehr rein.

Ich habe schon die TCP connections aufgebohrt, und die Drop Time reduziert, also die Zeit, nach dem eine geschlossene Verbindung dann tatsächlich fallen gelassen wird. Seit dem ist es besser geworden, aber irgendwann kommt es dann doch wieder.

Bisher bin ich noch nicht ganz sicher, ob es an mAirList liegt, aber die phänomene hören sich recht ähnlich an.

Greetz
Malte

3

Echte Hardware oder virtualisierter Server?

Die Soundkarte ist für die Taktung des Audiosignals zuständig. (Nutzt man den mAirList-Encoder und “keine Wiedergabe” als Ausgabe-Soundkarte, dann übernimmt die Windows-Realtime-Clock diese Aufgabe.)

Wenn das Signal irgendwann abbricht, dann bedeutet dass, dass in einem Zeitraum X weniger als X Audiodaten erzeugt wurden. Dass also die Samplerate der Soundkarte - oder die Realtime-Clock - nicht 100%ig richtig läuft sondern einen Bruchteil zu langsam.

Beispiel: Es hätten 60 Minuten Stream erzeugt werden sollen. Da die Realtime-Clock 0,003% zu langsam läuft, hat mAirList aber nur 59:50 Minuten Streamdaten erzeugt. Bei einem Puffer von 10 Sekunden im Player reißt der Stream in diesem Moment ab.

Solche Probleme sind mir üblicherweise von virtualisierten Servern bekannt.

4

Laut unseres Technikers läuft das komplette System auf einem realen Root-Server.

5

Kann das Problem eventuell gelöst werden, indem man mAirList nachts automatisiert beendet und morgens wieder startet?
Wir haben ein Havarie-System am Laufen, das einspringt, sobald mAirList sich aus irgendeinem Grund aufhängen sollte. Das würde dann in dieser Zeit einspringen, zumal wir von 1-6 Uhr in der Nacht eh nur eine Schleife laufen haben (Sendepause).

6

Also ich kenne etliche Installationen, wo mAirList seit Monaten ununterbrochen vor sich hin läuft, ohne solche Aussetzer.

Dieses Streamcontrol kenne ich nicht, daher weiß ich nicht, was das intern mit den Streams macht, und warum die anderen davon beeinflusst werden könnten. Sind da eigentlich igenwelche virtuellen Soundkarten im Spiel?

Habt ihr mal versucht, den mAirList-Encoder kurz zu trennen und dann neu zu verbinden? Reicht das evtl. schon aus?

7

Dieses Streamcontrol überwacht die Upstreams und leitet sie an Winamp weiter, welcher über das Shoutcast-DSP die Downstreams verteilt.
Sobald kein Upstream vorhanden ist, erstellt Streamcontrol eine eigene Playlist und schickt diese ebenfall an Winamp weiter, sodass Winamp dann die Titel abspielt und über Shoutcast rausschickt.

mAirList ist an Streamcontrol über einen Upstream gekoppelt.

Da Winamp die Brücke zwischen Shoutcast und Streamcontrol ist, wird eine virtuelle Soundkarte benötigt. Ohne diese funktioniert das System leider nicht.

Die Probleme sind erst aufgetreten, seitdem wir mit mAirList arbeiten. Vorher funktionierte alles von der technischen Seite her einwandfrei (Über den Programmablauf und -fluss brauchen wir uns an dieser Stelle nicht zu unterhalten :wink: )

8

Encoder trennen und starten bringt nicht viel. Das komplette System ist in Mitleidenschaft gezogen. Sobald wir mAirList komplett beenden, ist das Problem behoben.

Noch als Hinweis: mAirList nutzt die Soundkarte nicht. Alles wird direkt auf den Encoder ausgespielt, der es an Streamcontrol schickt. Streamcontrol schickt es an Winamp, der die virtuelle Soundkarte nutzt und schickt dann den Stream über Shoutcast-DSP raus.

9

hm, ich kenn das streamcontrol nicht, aber schon mal probiert direkt mit mairlist zu streamen ?
nur mal um zu sehen ob der fehler dann immer noch passiert.
ich kenn zwar nicht eure hintergründe, aber es klingt für mich nach einer hakligen baureihe (sry war scherz).

10

[quote=“deejaychriss, post:8, topic:9063”]Encoder trennen und starten bringt nicht viel. Das komplette System ist in Mitleidenschaft gezogen. Sobald wir mAirList komplett beenden, ist das Problem behoben.

Noch als Hinweis: mAirList nutzt die Soundkarte nicht. Alles wird direkt auf den Encoder ausgespielt, der es an Streamcontrol schickt. Streamcontrol schickt es an Winamp, der die virtuelle Soundkarte nutzt und schickt dann den Stream über Shoutcast-DSP raus.[/quote]

Gut, aber wie soll mAirList dann das gesamte System in Mitleidenschaft ziehen? Geht die CPU-Auslastung hoch oder was?

11

Das ist ja das was ich nicht verstehe! An der CPU-Last ändert sich nichts.

Insofern das gesamte (Streaming-)System in Mitleidenschaft gezogen, dass alle Streams, egal auf welchem Port, so lange stottern und buffern, solange mAirList läuft. Fahre ich mAirList runter, ist auf einmal jeder Stream wieder sauber.
Starte ich mAirList dann neu, geht alles für 2-3 Wochen wieder gut und dann geht der Spaß von vorne los.

12

Ja, das kann ich bestätigen.
So sieht das bei mir auch aus. RAM und CPU Last sind im grünen Bereich. Das kann man bei der virtuellen Maschine schön ablesen.

Es scheint mir fast also würde mAirList irgendwie die Netzwerkverbindungen fluten, so dass Windows abgelaufene Verbindungen nicht erkennt und löscht. Wir haben 3-4 mal täglich einen kurzen automatischen Disconnect vom Encoder, da wird über ein Script ein neuer ICQ Wert gesetzt. Darüber lesen wir die aktuelle Sendeung/ Moderator aus.

Kann es damit zu tun haben?
Vorher hatten wir das 1:1 so auf einem Win7 Rechner laufen, da hatten wir solche Probleme nicht. Der hat allerdings das Encoder Signal auf einer virtuellen Soundkarte an einen Silence Detector weitergereicht. Diese Virtuelle Soundkarte hatte gelegentlich mal Dropouts nach längerer Laufzeit. Der Dienst musste dann auch neugestartet werden.
Dazu musste man aber erst mal sämtliche Audioverbindungen trennen. Also das monitoring des Encoders ausschalten und am anderen Ende, den Silence Detector beenden. Dienst neustarten und alles wieder zurück.
Ich hatte Virtual Audio Cable am Start.
@deejaychris, kann das bei euch das Problem sein?
Vielleicht führt das beenden von mAirList nur zu einem Reset der virtuellen Audioverbindung?

13

Ich halte das mit den offenen Netzwerkverbindungen für ziemlich abwegig - aber wenn du wissen willst, welche Netzwerkverbindungen mAirList geöffnet hat, dann kannst du das in der Windows-Eingabeaufforderung (muss als Adminstrator ausgeführt werden) mit “netstat -ab” herausfinden.

Wenn auf dem System virtuelle Soundkarten installiert sind, die mAirList aber nich nutzen soll, dann bietet es sich an, alle in mAirList nicht verwendeten Audiogeräte auf “Keine Wiedergabe” zu stellen. Sonst passiert ggf. folgendes: Virtuelle Soundkarte ist Standard-Wiedergabegerät, dadurch mAirList z.B. der Cartwall zugewiesen, und auch wenn die Cartwall gar nicht verwendet wird, wird die Soundkarte unter Umständen (vorsorglich) geöffnet.

14

Nach langem hin und her überlegen denke ich, dass wir auf das Problem nun vllt lösen konnten. Sicher bin ich mir noch nicht. Wir müssen eine Zeit lang beoabchten und werde dann noch einmal berichten, ob das Problem gefunden und gelöst ist.

Hier noch einmal die genaue Problem-Darstellung, bzw. die Kofiguration:

  • Streamcontrol (Standalone) zur Überwachung der Upstreams. Dieses Programm macht nichts anderes, als die Stream-Adressen weiter zu leiten! Das heißt: Es laufen im Task mehrere Shoutcast-Server-Instanzen. Solange diese nicht befüttert werden, leitet Streamcontrol diese nicht an Winamp weiter. Kann Streamcontrol keinen Upstream erkennen, erstellt es selbstständig eine Playlist und füttert damit den Winamp.
  • Winamp mit Shoutcast DSP zur Verteilung der Downstreams.

Nun kann man im Streamcontrol den Upstreams verschiedene Prioritäten zuweisen.

Die Erstellung der eigenen Playlist hat die geringste Priorität.

mAirlist hat die nächst höhere Priorität. Sobald also mAirList on Air geht, wird dieser Stream an Winamp weitergeleitet.

Die Moderatoren haben die nächste Priorität. Sobald also jemand auf Sendung geht, wird dieser Upstream an Winamp weitergeleitet, ungeachtet dessen, dass mAirList immer noch on Air ist, weil dieses ja eine niedrigere Priorität hat.

Und hier genau liegt das Problem. Die Shoutcast-Instanz, die von mAirList gefüttert wird hat in genau diesem Moment keinen Abnehmer, weswegen wahrscheinlich der Buffer voll läuft, solange jemand auf anderes auch noch auf Sendung ist. Denn Streamcontrol lässt mAirList ins Leere laufen, weil es ja die Anweisung hat, den sendenden Moderator an Winamp weiter zu leiten.
Sobald kein Modi mehr auf Sendung ist, also kein Upstream mit höherer Priorität auf Sendung ist, wird der mAirList-Stream wieder durchgeschaltet. Damit wird zwar der Buffer wieder abgebaut, aber Altbestände des Streams bleiben trotzdem im Cache. Das geht so lange gut, bis der Buffer überläuft. In diesem Momentan werden alle Shoutcast-Instanzen in Mitleidenschaft gezogen. Da Streamcontrol die Anweisung hat, jeden Stream neu zu starten, wenn er getrenn t ist, war auch die logische Schlussfolgerung: mAirList beenden und der Shoutcast-Cache ist wieder leer.

Dementsprechend werden wir nun jede Nacht den Encoder von mAirList automatisch trennen und morgens wieder connecten, sodass sich der Buffer leer räumen kann.

Ich hoffe, ich konnte es einigermaßen verständlich erklären. Wenn nicht, einfach nochmal schreiben :slight_smile:

15

Das ist bereits von Anfang an geschehen. Wie bereits geschrieben: Die virtuelle Soundkarte wird von mAirList garnicht berücksichtigt.

16

Schriebst du nicht oben, dass das nichts geholfen hat?

17

In dem Glauben war ich auch, weil unser Techniker das so erzählt hat. Er sagte, er hätte mAirList beenden müssen. Muss allerdings sagen: Er hat von mAirList absolut keine Ahnung, weswegen ich mich darum kümmere. Er ist von der Software nicht überzeugt und meint, sein Streamcontrol könnte das auch alles. Das stimmt auch bedingt, aber trotzdem wird die Musik letztendlich vom Winamp abgespielt und wie sich damit ein Radio-Programm anhört, darüber brauchen wir uns glaube ich nicht unterhalten :slight_smile:

Ich mache das jetzt einfach mit dem Encoder trennen und wieder connecten. Außerdem habe ich auf Anraten eines Freundes noch nen Aircheck im mAirList angelegt. Angeblich soll dieser das Buffern abfangen.

18

Ahh! -ab war der Parameter, den ich gesucht habe. Danke.
Du hast recht, da stehen nur 2 Verbindungen. Eine für die Remote Steuerung und einmal die ausgehende Encoder verbindung. Ich hab inzwischen sogar die Abfrage der Hörerzahlen deaktiviert.

Das werde ich mir noch mal ansehen, wenn das Problem wieder auftaucht. In den letzten 3 Wochen war nix.

Die einzigen beiden, die reichlich Ports offen halten sind TeamViewer und SC_SERV.

19

Nun stehen wir wieder vor dem gleichen Problem und ich bin echt langsam am Verzweifeln! Trotz der nächtlichen Trennung vom Stream taucht nach knapp 2 Wochen das Problem wieder auf, dass alle Streams in Mitleidenschaft gezogen werden und alles nur noch ruckelt. Erst nach Beendigung von mAirList selber hat sich das Stream-System wieder erholt. Jemand nen Lösungsvorschlag! Wenn das alles nichts bringt, wird unsere Sendeleitung mAirList wieder runterschmeißen und wieder mit Winamp arbeiten.

Im Übrigen hatten wir eine Prozessor-Last von 40% nach Beenden des Prozesses mAirList lag die Prozessor-Last bei 5%.

20

Ich würde den Fehler eher im Bereich der virtuellen Soundkarte suchen.
Das ist ohnehin ein ziemlich wirres konstrukt, was ihr da fahrt. Die sauberste Lösung ist immer noch, direkt auf einen Encoder und dann zum Streamserver zu gehen. Bei eurem Konstrukt sind Probleme vorprogrammiert. Das muss nicht zwingend etwas mit mAirList zu tun haben.

Wenn Du ein Backup brauchst, für den Fall, dass mAirList mal quer liegt, kann das SC_Trans 2 ganz gut auffangen. Ist mir aber noch nie passiert und wir fahren schon einige Jahre gut damit. Wenn ein fehler passiert, dann weil jemand eine Playliste bearbeitet und nicht gespeichert hat.

Greetz
Malte