Hi,
folgendes Phänomen: Nach einem Wochenende Automation hängt die grafische Darstellung in der Playlist, bei den Playern und in der Cartwall im Assist Modus etwas hinterher. Der Sound wird aber einwandfrei wiedergegeben. Hat jemand einen Tipp woran das liegen kann?
Bei Mairlist 2 hatten wir das Problem nie… Grüße
Prinzipiell ermöglicht wird das in mAirList 3.0 durch das Multithreading und die asynchrone Kommunikation zwischen GUI und Kontrollklassen. Vorkommen sollte es aber trotzdem nicht, insofern bist du hier im Bugs-Forum schon richtig.
War es eher so, dass die Aktualisierung der GUI zwar zeitverzögert war aber immerhin noch automatisch? Oder hat sie sich gar nicht mehr automatisch aktualisiert, sondern nur noch, wenn man manuell im Fenster herumgeklickt hat?
Doch, hat sich selbst aktualisiert, keine weiteren Veränderungen zur “fehlerlosen” Performance. Nur eben komischer Weise leicht zeitversetzt. Nach einem Neustart von Mairlist ist das Problem weg. Wir feuern die Songs ja direkt mit Start Stop am Mischpult ab und das Szenario läuft wie folgt ab:
Start Taste drücken: Song läuft sofort an aber grafisch passiert erst nach ca. einer halben Sekunde etwas.
Hm. Klingt ein bisschen so, als ob sich da Nachrichten “aufgestaut” hätten, die nicht schnell genug abgearbeitet werden konnten.
Kannst du sagen, ob das plötzlich aufgetreten ist oder sich eher mit der Zeit aufgebaut hat?
Ich werde demnächst selbst noch einige Langzeittests durchführen (stelle gerade noch die Hardware dafür zusammen). Dann werde ich mal gezielt auf solche Effekte achten.
Falls sich das Problem bei euch reproduzieren lässt, würde ich euch auch gerne eine spezielle Debug-Version zukommen lassen. Sag also bitte bescheid, wenn das nochmal vorkommt.
Ja, ist reproduzierbar. Der Fehler tritt immer dann auf, wenn lange AUTO Mode läuft. Also bei uns immer am Wochenende, da da VP - Sendungen laufen. Wenn ich dann Montag auf ASSIST umschalte, braucht der dazu kommende Player “ewig” bis er sich geladen hat (aber nur beim Umschalten, dann gehts schnell) und Sound und Display stimmen nicht mehr überein…
Ach ja - macht in der Tat den Eindruck als ob sich da etwas “anstaut”!
Gern. Immer her mit der Debug Version. Wir helfen gern… ;-))
Reproduzierbar ist gut, dann steigt die Wahrscheinlichkeit, dass der Fehler leicht zu beheben ist.
Neben mir läuft gerade die Installation von Windows XP auf einem Testrechner…
XP is immer gut 
Querdenk…
dieses Phänomen passt ja auch ein wenig mit der Midi Sache wo sich die Daten anscheinend ein wenig anstauen.
Aber wo ich das mit der GUI lese… gabs da nicht schon mal ein ähnliches Problem (auch mit Umschalten aus Automation in Assist) vor gar nicht allzulanger Zeit was schon bearbeitet wurde?
Welche Version habt ihr denn drauf? @ Plattenschubse
Grüße
Hi,
wir haben jetzt 3.0.4 Build 571. Grüße
Gibts nach dem Langzeittests schon Neuigkeiten? Ich habe das Problem tatsächlich jetzt immer, wenn das Programm lange auf AUTO stand… Grüße
Ich hatte den Rechner letzte Woche mal drei Tage laufen lassen - ohne Probleme. Im Moment ist er mir zu laut, und in meinem Büro ist es auch so warm genug 
Ich schau mal, dass ich dir eine spezielle Debug-Version fertigmache, die ein paar zusätzliche Informationen über Verzögerungen in der Nachrichtenbearbeitung ausgibt.
Wäre cool, Danke!!
So, die Debug-Version liegt hier: http://www.mairlist.com/download/mAirList/v3.0/debug/
Ist zu verwenden wie ein normaler Snapshot.
Es geht ein zusätzliches Fenster auf, in dem du Statusmeldungen wie diese hier siehst:
19:11:37 VCL: delay 1, time 0: AUDIOSOURCE_CUEDATA_MARKER
19:11:37 Sync: delay 0, time 0: PLAYBACKCONTROL_CHANGE 0
19:11:37 Thread: delay 1, time 0: PLAYERCONTROL_CHANGE 0 0Die einzelnen Objekte in mAirList kommunizieren ja untereinander mittels spezieller Nachrichten. In diesen Debug-Meldungen siehst du, welche Nachrichten verarbeitet wurde, mit wieviel Verzögerung (in ms), und wie lange es gedauert hat (auch in ms). Davor steht noch “VCL” (Nachricht an ein GUI-Object), “Thread” (Nachricht an ein Objekt mit eigenem Messaging-Thread, zum Beispiel die Playlist oder die Player) oder “Sync” (Nachricht an ein normales Objekt).
Wie du sehen wirst, bewegen sich die Zeiten normalerweise im Bereich von wenigen Millisekunden. Mich würde nun interessieren, ob die Zeiten signifikant ansteigen, wenn der von dir geschilderte Effekt eintritt.
Hi,
danke für die Version. Ich warte das Wochenende über und melde mich am Montag dann, wenn der Effekt wieder eingetreten ist…;-)) Grüße
Also,
hab die Debug Version jetzt mal ein paar Tage laufen lassen. Ich komme mit den ganzen Daten nicht so zurecht. Fakt ist auf jeden Fall, dass beim Umschalten nach langem Auto Betrieb auf Assist ein Delay von 200ms dauerhaft zu verzeichnen ist. Im Übrigen stimmt dann auch die Ramp Anzeige nicht mehr. Ramp akustisch vorbei während noch eine angezeigt wird. Im Cue Modus ist sie aber korrekt eingestellt und stimmt auch optisch… Komisch…
Davon gehe ich aus. Daher wäre es gut, wenn ich die Daten mal sehen könnte.
Ich habe die Debug-Version inzwischen nochmal aktualisiert. Es wird nun eine Datei “debug.txt” geschrieben, die du mir prinzipiell zuschicken könntest - wobei ich befürchte, dass die bei einem Testlauf über’s Wochenende ziemlich groß werden könnte. Probier’s einfach mal.
Mach ich,
wo finde ich die Datei? Gruß
Ähm, da wo du die andere auch her hattest?
beim aktuellen snapshot tritt was ganz seltsames auf.
wenn ich den player starte, dann werden verschiedene scripts ausgeführt.
wenn ich aber jetzt den player starte, dann werden diese am anfang nichtausgeführt. erst wenn ich den fader bewege, also player volume.
ganz seltsam …
habe gerade herausgefunden, dass das nur auftritt, wenn man eine mairlistDB verbindung hat … ??? …