Moinsen,
Wenn ich aus einer Datenbank eine Playlist/Sendeplan lade, hängt sich das Programm auf. Das ganze tritt auch bei einzelnen Titeln tritt das Problem auf.
Evtl. wichtig: Ich verbinde mich auf einen Datenbankserver “außer Haus”.
Danke und LG
Konstantin
Und das äußert sich wie genau?
Auf jeden Fall. Auch wichtig:
Das Fenster friert ein (also alles innerhalb von mAirlist. Wenn ich dann versuchen sollte irgendwas an mAirlist zu machen, stürzt das Fenster machmal ab.
Werden heruntergeladen
Soweit ich weiß nicht, nein.
mp3
Habe hier schon mit den verschiedensten Werten rumgespielt, Ergebnis bleibt gleich.
Ich habe hier eine 100k Leitung, der DB Rechner hat knapp 1/10 davon.
Meine Frage wäre noch: Welche Version genau hast du da im Einsatz? v7.1 oder v7.2? Snapshot oder Release-Version?
Guten Morgen,
Wie lange dauert das “Einfrieren”, bis es wieder läuft?
Generell gilt: Wenn mAirlist “einfriert”, warte bitte, bis es alle Operationen ausgeführt hat und klicke nicht wild ins Fenster. Sollte ein Play Out im Hintergrund laufen, spielt es problemlos weiter. Nur die grafische Oberfläche ist eingefroren.
100K ist entsprechend der Download bei Dir.
Wenn der Server-Rechner 1/10 davon hat, also entsprechend DSL 10.000, dann ist das im Upload zu Deiner mAirlist-Instanz noch deutlich weniger.
Kommunizieren beide Rechner miteinander, kann es dadurch zu deutlichen Verzögerungen kommen, wenn viele Daten vom dB-Server geladen werden müssen.
Verbinden sich nun auch noch mehrere Nutzer gleichzeitig oder arbeiten per Remote an der Datenbank, reduziert sich die Geschwindigkeit entsprechend. Sendet der Server zusätzlich einen Stream raus, wird es noch weniger.
Bei einem Downstream von 10k liegt der Upstream bei vermutlich um die 400 bis 800kBit/s (16k bei der Telekom = 1024kBit/s Upstream).
Entsprechend langsam dürfte die Kommunikation und das Übertragen der Playliste alleine sein.
Ich gehe jetzt mal davon aus, dass mindestens Player A und B beim Laden der Playliste automatisch geladen und deshalb vorgespeichert werden?
Hast Du zwei MP3 mit 320kbs und ca 7 bis 9 MB pro Datei, benötigt Dein mAirlist schon etliche Sekunden, um bei der geringen Upload-Geschwindigkeit des dB-Rechners die Playliste samt der ersten beiden Titel herunterzuladen und bereitzustellen.
Alle weiteren Titel werden “im Hintergrund” gebuffert, da sollte das Playout nicht einfrieren. Für das initiale Laden der PL spielen diese Werte, wie Du festgestellt hast, deshalb auch keine Rolle.
Abhilfe wird hier nur eine deutliche Erhöhung der Server-Upstream-Geschwindigkeit schaffen, eine lokale Spiegelung der Titel bei Dir auf dem Rechner oder einfach mehr Geduld.
Mein persönlicher Tipp: Bindet die Musik über eine Netzwerkplatte von z.B. Hetzner ein (1TB = 3,81 Euro). Der Server sieht das als “lokale” Festplatte und in Deinem Rechner kannst Du dieses Netzlaufwerk als lokale Spiegelung angeben.
Damit entlastest Du den Upstream des db-Servers erheblich.
Version macht hier keinen Unterschied, habe auch mal testweise die v6 auf einem Zweitsystem getestet und bin zum gleichen Ergebnis gekommen.
Hallo @Konstantin,
bist du bitte so nett und trägst noch die Seriennummer deiner mAirList-Lizenz ins Forenprofil ein? Das, was aktuell dort steht, ist keine Seriennummer. 
Vielen Dank.
Eine Anmerkung:
Inwiefern ihr euch untereinander Daten zur Verfügung stellt, ist eure Sache, kann aber in gewissen Konstellationen auf juristisches Glatteis führen. Das müsst ihr wissen, nicht wir.
Aber: Der Zugriff auf eine Sender-Datenbank über den mAirListDB Server bietet die Sicherheit, dass ggf. unerwünschte Downloads (Kopien) der auf dem Server gelagerten Musikstücke verhindert werden und die Dateien nur zu Ausspielzwecken in den Arbeitsspeicher wandern.
Je nach gewünschter Anwendung und eventuell nötiger Rechtssicherheit ist der mAirListDB Server die verlässlichere Alternative.
Was die von Stefan errechneten Bandbreiten angeht: Einen Server mit einer vergleichsweise dünnen Leitung (speziell Upstream) kann auch ich mir nur schwer vorstellen.
Frage: Handelt es sich möglicherweise um einen “shared” Server?
Liegt das Problem also am Buffern der Player in Kombination mit einer langsamen Internetleitung?
Wäre es dann nicht seitens mAirlist sinnvoller sich nicht aufzuhängen sondern stattdessen eine Ladeanimation/Kreis etc. zu zeigen?
Ich verstehe nicht wieso das gleich zu einem Freeze führen sollte…
Definitiv. Ich habe das auch schon moniert - einige der “Freeze”-Fehlermeldungen hier im Forum lassen sich ja darauf zurückführen, dass panisch geklickt wurde, wenn mAirlist sich nicht mehr rührte. Dabei läuft das Playout ja zuverlässig im Hintergrund weiter.
Dass man in der gesamten Zeit nichts mehr machen kann, nicht mal eine Cartwall abfeuern, ist allerdings wirklich unpraktisch.
Technisch kann das wohl nur Torben erklären…
Jeder Prozess gliedert sich in mehrere “Unterprozesse” (Threads), die gleichzeitig Code ausführen können.
Dabei gibt es genau einen Haupt-Thread, der für die Verarbeitung der GUI zuständig ist, also Fensterinhalte zeichnen, Mausklicks und Tastatureingaben verarbeiten etc. - daher auch “GUI-Thread” genannt.
Wenn man jetzt z.B. einen einfachen Handler für einen Button programmiert, der irgendeine langwierige Operation ausführt - zum Beispiel das Herunterladen einer Datei - dann wird dieser Code standardmäßig auch im GUI-Thread ausgeführt mit dem Ergebnis, dass der GUI-Thread in der Zwischenzeit nichts anderes machen kann, also weder die Anzeige aktualisieren noch auf irgendwelche anderen Benutzereingaben reagieren.
Das berühmte “the application seems to be frozen” kommt dann, wenn der Main-Thread auf diese Weise länger als 60 Sekunden beschäftigt war und keine GUI-Operationen mehr durchführen konnte.
Programmiertechnisch kann man dem Problem in Delphi auf zwei Arten begegnen:
Während der Ausführung der Operation dem GUI-Thread immer mal wieder explizit die Gelegenheit gegeben, GUI-Nachrichten abzuarbeiten (mittels Application.ProcessMessages). Das geht aber nur dann, wenn die langwierige Operation ihrerseits aus vielen kleinen Schritten besteht, die immer mal wieder zwecks GUI-Updates unterbrochen werden können. Beispiel: 1000 Dateien importieren, dann kann man nach jeder Datei kurz ein GUI-Update machen. Dieser Fortschrittsdialog, den ihr an vielen Stellen im Programm seht, handhabt das so. Nicht funktionieren tut das aber bei “atomaren” Operationen, bei denen ein einzelner Schritt schon sehr lange dauert. Beispiel: Eine HTTP-Anfrage, für deren Beantwortung der Server schon sehr lange braucht, bis überhaupt das erste Byte der Antwort fließt.
Die komplette Operation in einen neu zu startenden Hintergrundthread verlegen, der vor sich hinläuft, während der GUI-Thread einfach nur auf das Ende der Operation wartet, einen Dialog anzeigt und dabei alle paar Millisekunden mal GUI-Nachrichten abarbeitet. Das ist eigentlich der eleganteste Weg, programmiertechnisch aber auch der komplizierteste, weswegen ich das nur sehr dosiert einsetze dort, wo Operationen wirklich lange brauchen. Sollte es eurerseits Vorschläge geben, an welchen Stellen man das noch so handhaben sollte, bitte immer gerne äußern.
Danke dir Torben für die detaillierten Ausführungen!
Ich würde mich ehrlicherweise genau bei diesem Problem darüber freuen. Es mag zwar nicht bei jedem Vorkommen, jedoch ist es für die die damit arbeiten müssen, immer eine Spaßbremse.
Es wäre zunächst zu klären, was hier überhaupt die langwierige Operation ist. Das Laden des Sendeplans sollte eigentlich nicht so lange dauern, selbst beim Betrieb über einen (langsamen) DBServer. Denn die Audiodateien werden da noch gar nicht übertragen, das passiert erst später beim Vorpuffern bzw. beim Laden in den Player - und zwar jeweils bereits in einem Hintergrundthread.
Dauert es auch schon so lange, wenn du im Datenbank-Playlist-Browser zwischen den Stunden hin- und herwechselst?
Kurz, ja.
(Ich muss hier noch auf 20 Zeichen kommen)
Dann haben wir vermutlich schlechte Karten, da es sich um eine “atomare” Operation handelt (warten auf Antwort des HTTP-Servers).
Ist die Datenbank allgemein so langsam? Auch wenn man direkt “am Server sitzt”?
Also ich kann aus persönlichen Situationen berichten, in dem die Verbindung und das Arbeiten mit einer Datenbank die per Windows Server verbunden ist, enorm vom Internetanschluss abhängt.
Hatten den Fall das beim Kollegen allein das Laden eines einzigen Titels im Cueeditor bis zu 20 Sekunden gedauert hat, während es bei mir nicht mal eine Sekunde dauerte. (Selbe DB auf Server)
Genauso verhielt es sich beim laden der Playliste. Die Playliste selbst (Liste) war schnell da aber bis die Titel auch wirklich vorgeladen waren, dauerte es ewig. Auch hier war ein freeze feststellbar.
Schuld war ein noch alter DLAN Stecker der ins Studio eingebunden war. Neben diesem liefen auf dem Stromnetz noch zwei weitere, neuere D-Lan Module. Nachdem wir den alten ausgetauscht hatten, flutschte es wie es soll.
Daher würd ich zumindest erst mal einen eventuellen Flaschenhals ausschließen. Auch wenn am Router…
… ankommt, bedeutet es noch nicht das diese auch am Rechner ankommen.
Insofern dort alles passt, bin ich raus 
Diese Fragen wurden bereits direkt bzw. indirekt beantwortet, sie haben nichts mit dem Client-Rechner zu tun:
Der Flaschenhals ist ganz offensichtlich der Internet-Anschluss des Servers mit rund 10k DSL. 
Es wäre schon hilfreich, wenn der User per MIttleilung über das Abarbeiten einer Aufgabe informiert würde, also zum Start der Aufgabe ein Fenster eingeblendet wird a la:
“mAirlist führt eine Aufgabe aus, bitte haben Sie Geduld. Das Playout ist davon nicht beeinträchtigt”.
Wer Angst hat, dass mAirlist in einer laufenden Sendung gecrasht ist, wird wild herum klicken. Das könnte die Panik mildern.
Das fänd ich einen guten Anfang. Alles was das Gefühl gibt, dass etwas passiert, gibt Sicherheit und man gerät nicht gleich in einen (leicht) panischen Zustand.
Bist du denn der einzige der auf die DB zugreift? Oder gibt es noch Kollegen die auch einen Zugang haben? Wenn ja tritt das dort auch auf?
Wenn nein, könnte man mal, unter Aufsicht versteht sich, eine Probeverbindung aus einem völlig anderen Ort gegentesten. Nur als Vorschlag.
Im privaten und nicht öffentlichen Kreis versteht sich.
