mAirList Advanced Server (Home) - Absturz/Freeze nach erneutem Log-In

Deutsch / German mAirList 7.x
1

Tag auch!

Folgendes spielt sich bei mir ab: Wenn ich mich nach der Arbeit zuhause wieder per RDP auf den Server einlogge, scheint mAirList eingefroren zu sein, zumindest die GUI, denn das Playout läuft weiter.

Ich bekomme “List Index out of bounds”, “Call to an OS function failed” und irgendwas mit einem Klassenfehler. Die Bugreports sind bereits unterwegs, möchte die Situation aber hier gern noch weiter erläutern:

Ausgangssituation: mAirList läuft auf dem Server minimiert, mit Icon in der Taskleiste und Stereotool als DSP. Wenn ich mich mehrmals am Tag einlogge kann ich mL problemlos öffnen. Wenn ich mich aber über mehrere Stunden NICHT einlogge (Abwesenheit wegen Arbeit), passiert der oben angegebene Fall.

Ob das morgens nach der Nachruhe auch geschieht kann ich nicht sagen, weil ich mich da noch nicht einloggen wollte. Ich hole das aber gerne morgen früh nach, sollte es zur Fehlersuche beitragen.

Aus der Situation kann ich mich nur durch dern Taskmanager befreien, bei jedem Versuch, die GUI im ja eigentlich laufenden Betrieb irgendwie zu öffnen, wird mit einem erneuten “List index”-Fehler belohnt.

Habe ich vll. irgendwas falsch eingestellt für den Serverbetrieb? Liegt es vielleicht am Windows Remote Audio?

Vielen Dank schonmal für euere Hilfe und Lösungsansätze! :slight_smile:

Gruß
Myka

2

Laufen denn bei Dir irgendwelche Skripte?

3

Ja, diese beiden:

Auto-Button.mls (855 Bytes)
On-Air.mls (803 Bytes)

Die laufen aber lokal bei mir problemlos. eigentlich seit Jahren schon :open_mouth:

Edit: Und auch auf dem Server tun sie artig, was sie sollen.

4

Wie lauten denn die Fehlermeldungen genau? Wo sind sie her? Aus dem SystemLog?

5

Ich mache morgen Screenshots, die Fehlermeldungen tauchen als Pop-Ups auf. Ins mL-Syslog konnte ich ja nicht schauen, ich kam ja ans GUI nicht mehr ran :open_mouth:

Nachtrag: Im gespeicherten Log tauchen keine Meldungen auf, da ist nichts vermerkt.

6

Es müsste eigentlich noch eine bugreport.txt generiert worden sein. Glaube aus dieser würden schon diese Informationen reichen:

exception number
exception class
exception message

(Zumindest hier im Forum)

7

Die sind bereits versendet, wie eingangs erwähnt :slight_smile:

8

Dann müsstest du jetzt auf Torben warten. Mit der Fehlermeldung hätten wir immerhin auch hier einen Anfang :sweat_smile:

9

Einen habe ich sogar gespeichert:

exception number   : 1
exception class    : EOSError
exception message  : System Error. Code: 1410. Klasse ist bereits vorhanden.
1 Like
10

Nutzt Du denn Audio über die Remote-Verbindung, oder ist Audio in RDP ausgeschaltet?

11

Ja, ist eingeschaltet. Ich nutze es, um die Ausgabe zu kontrollieren (StereoTool-Anpassungen, Mix-Editor, PFL etc.), aber sollte ich darauf vll. besser verzichten?

Fand es halt ganz angenehm, so eingreifen zu können, aber wenn Windows da irgendwie bockig ist, deaktiviere ich es wieder…

Nachtrag: Ich hatte die Fehler eben erneut, und ich weigere mich, mAirList die Schuld zu geben, denn lokal hatte ich das in meiner ganzen mAirList-Lebenszeit noch nie, ich schieb’s auf Windows 2019… :slight_smile:

12

In manchen Fällen kann es eventuell Probleme machen. Das habe ich auch schon erlebt.
Aber nutzen kann man es eigentlich.

Versuch mal die Remote-Audio erstmal auszuschalten. Ob das schon hilft.

Genau das :wink:

13

Hab es jetzt komplett deaktiviert, lasse mAirList eine Weile werkeln und schaue, ob es später erneut auftritt :wink:

1 Like
14

Ja. Sobald die RDP einen neuen Client verbindet, fliegt Audio raus. Problem: Ist das als Routing für PFL gesetzt und die „Soundkarte“ ist plötzlich weg, kann mAirList einfrieren.

So, als wenn Du an Deinem Rechner die Soundkarte trennst.

Ist ein Klassiker, daher fragte ich nach RDP.

1 Like
15

Riecht nach der Lösung… Ich hab Remoteaudio komplett deaktiviert auf dem Server, auch in der RDP-Datei rausgenommen… Ich lasse mAirList wie erwähnt jetzt eine Weile laufen und logge mich dann wieder ein nach ein paar Stunden, dann sehen wir, ob es das war :wink:

Vielen Dank an alle, wie üblich! :hugs:

16

Ja, das kenne ich aus mAirList v6.x.
Da hätte ich das auch noch unterschrieben.

Nun sind wir aber in mAirList v7 (zumindest steht der Thread dort) und Torben hat, neben einigen anderen Änderungen im Routing, auch folgendes eingebaut:

[+] WASAPI: Automatic recovery when devices are disconnected and reconnected

Quelle: https://download.mairlist.com/current/mAirList/v7.0/Changelog.txt, Abschnitt “New features”.

Nach meiner Kenntnis heißt das, wenn bspw. ein Interface die Verbindung “verliert” (Wackelkontakt, Stromausfall), dann fällt mAirList störungsfrei auf den Windows Standard zurück.
Zumindest habe ich das mal so gelernt.

Jetzt die Fragen an die Support-Profis:

  1. Stimmt meine These (noch)?

  2. Falls ja, warum greift dieses fallback nicht bei RDP mit dem Windows Server?

Dem programmierten Algorithmus in v7 sollte es doch egal sein, ob ich eine physische oder eine virtuelle Soundkarte trenne und wieder neu verbinde.

Würdet ihr mich bitte mal auf den aktuellen Stand bringen?
Danke.

17

Das tut es lokal bei mir ja auch, wenn ich zum Beispiel meinen Bluetooth-Kopfhörer verbinde, schaltet mAirList brav um, von daher unterschreibe ich das.

Was aber, wenn auf dem Server das Remoteaudio (logischerweise) die einzige “Soundkarte” ist und diese getrennt/wiederverbunden wird?

18

Mich dünkt, es liegt am “Wiederverbinden” beim erneuten einloggen, so als ob Windows beim Ausloggen aus dem RDP das Remoteaudio nicht ordentlich trennt/entfernt und irgendwo noch “Reste” hängenbleiben… :open_mouth:

19

Dark Mode an oder aus?

20

An. Hab meinen Skin “mitgenommen”, umn mich wie zuhause zu fühlen :smiley:

Aktuell kann ich berichten, das es zu funktionieren scheint. Remoteaudio ist nur für alle PFL-Routings aktiviert, alles andere ist auf “Keine Wiedergabe” gesetzt.