Gefühlt nach dem letzten Snapshot habe ich extrem lange Ladezeiten, wenn ich auf den Eigenschaften-Dialog oder direkt das Extra-PFL öffne. Ich habe es zunächst auf die Datenbank geschoben und diese auf meine SSD verschoben, was aber keine Auswirkungen hatte.
Ob es jetzt nun tatsächlich am Snapshot liegt kann ich nicht beurteilen, aber ich hatte ihn installiert ohne mAirList vorher nochmal zu starten. Änderungen am System gab es nur durch die Installation der ESI Gigaport HD.
Das Problem tritt scheinbar nur bei Elementen auf, die noch nicht nachträglich (nach der Synchronisierung) berbeitet wurden. Elemente, die bereits mit Cue-Punkten u.ä. versehen wurden verhalten sich “normal”.
Vielleicht hilft das bei der Eingrenzung der Fehlersuche.
Kommando zurück, auch wenn Cue-Punkte editiert wurden, öffnet sich das Fenster sehr spät, es gibt sogar eine “frozen”-Meldung.
Ich kann es aber auf folgende Situation eingrenzen:
Ich habe zwei Datenbanken eingerichtet, eine, aus der sich die Automation bedient (Datenbankplaylisten durch den Scheduler erstellt) und eine mit dem gesamten Archiv. Ziehe ich Songs aus dem Browser (ob über die Suche oder den Datenbank-Ordnern) in die Playlist und will an die Eigenschaften oder den Extra-PFL kann ich mir erst mal einen Kaffee holen gehen, was onair natürlich weniger günstig ist.
Die Archiv-DB ist natürlich um einiges umfangreicher und grösser als die andere, kann es daran liegen?
So, ich kann es zumindest auf die zweite Datenbank schieben, in der sich das gesamte Archiv befindet (diese habe ich sogar noch einmal neu angelegt). Ist die aktiv und ich füge (auf alle Art und Weisen) einen Track in die Playlist und möchte entweder die Eigenschaften oder den EXTRA-PFL öffnen, so dauert dies wirklich lange.
Befindet sich das Element aber bereits in der kleineren Automations-Datenbank, so öffnet sich alles in gewohnter Weise. Dies ist mir bis jetzt subjektiv auch erst seit V5.x aufgefallen. Möglicherweise gab es das Problem vorher schon und ich habe es nur nie bemerkt…
Ich werde versuchen, das nachher noch einmal mit verkürztem Time-Out zu “generieren”, um Dir einen Bug-Report zu schicken.
Also in dem Bugreport hängt es beim Zusammensuchen der Ordner, das kann eigentlich nicht lange dauern. Aber es werden ja noch andere Dinge geladen in dem Schritt, der Verlauf etc.
Mach doch mal eine Sicherungskopie der Datenabank und kürze dann den Playlist-Verlauf auf 7 Tage oder so. Das geht in v5 im Konfigurationsdialog der Datenbankverbindung. Geht es dann schneller?
Ausgeführt. Leider kein Effekt, dauert genauso lange (bis zu einer Minute).
Hätten die Synchronous-Modi darauf evtl. einen Effekt? Und was ich mir noch vorstellen könnte: Windows 8.1, denn das ist eigentlich die elementarste Änderung an meinen Systemen, hardwareseitig war sonst nur der Wechsel zu SSD’s. Das dürfte aber eigentlich keine Auswirkungen haben, denn die Datenbanken liegen auf der USB-Platte zusammen mit den Elementen (damit ich die Sendeplanung bequem im Wohnzimmer machen kann, Dongle sei Dank…). Aber es hat ja sonst auch so funktioniert. Und ich hatte die DB’s auch schon testweise auf die SSD’s kopiert und von dort verwendet, aber das brachte auch nichts.
Datenbankgröße ist übrigens bei rund 20 MB, mit etwas über 40.000 Elementen.
Edit: Es ist im übrigen unabhängig, ob mAirList auf dem Laptop oder dem ungleich leistungsfähigeren Senderechner läuft…
Mir kommt grad eine Idee: Liegt es vllt. daran, das ich die Ordnerstruktur beibehalten habe? Denn das sind ja richtig viele Ordner, die von mAirList virtuell angelegt werden mussten…
Ich bin halt sehr genau, was alle meine Ordnerstrukturen betrifft. Speziell im Bereich des Archivs, die Aufteilung stammt noch aus Zeiten, wo ich keine Datenbank hatte. Das Suchen ging so schneller…
Wenn das tatsächlich die Ursache wäre, dann ist es vielleicht denkbar, das “Beibehalten der Ordnerstruktur” zu begrenzen (irgendwo editierbar), z.B. auf zwei bis drei Ebenen.
Hiesse in meinem Fall, das nur die Unterordner mit den Genres angelegt werden würden bei Auswahl auf eine Ebene, also der oberen.
Zur weiteren Fehlersuche lese ich das Archiv gerade noch einmal ohne die Übernahme der Ordnerstruktur ein. Vielleicht ergibt sich dann ja ein “Aha”. 8)
Soll heissen: Die Performance nach Anlegen eine neuen Datenbank und dem Importieren ohne Übernahme der Ordnerstruktur hat sich um ein Vielfaches gesteigert, also muss die Anzahl der virtuellen Ordner tatsächlich von Bedeutung sein!
Ich vermute, dass der Algorithmus, der die Ordnerstruktur aus der DB liest, nicht wirklich der effizienteste ist. Werde mir das noch anschauen, hatte noch keine Zeit. Schmeiß die alte DB bitte nicht weg, ich brauche dich als Tester
