So Windows ist neu installiert.
Und heute Nacht… wieder abgestürzt. ??? ??? ???
So 2 Sachen probieren wir noch aus:
- Soundkarte austauschen
- Andere Bass.dll
- Anderer PC
Sohoo…
neuer PC… mAirList DB ist immer noch bei 40.000Titeln immer noch sau lahm. Ein Titel in der Datenbank verschieben dauert geschlagende 10 Sekunden und länger… von der Suche ganz zu schweigen.
Lieber Torben woran könnte das liegen?
Ich hab ca. 28000 Elemente in der DB und nen lahmen 2,4 Ghz PC mit WinXP, aber trotzdem keine langen Ladezeiten…
Was habt ihr für einen Rechner und welches Windows?
Windows XP… PC relativ neu… kann gerade keine Details nennen bin nicht im Studio…
Titel sind in Ordner A, B, C, D… gespeichert.
Verschieben im Sinne von von einem Ordner in einen anderen?
Verschieben im Sinne von Titel in einen anderen Ordner schieben.
Kleiner Hinweis:
Suchstring: Shania= 6 Sekunden (wovon nur Titel von Shania Twain dabei sind).
Tja, 40000 Titel, Volltextsuche, über mehrere Tabellen (Interpreten, Titel, Attribute), da kommen 6 Sekunden gut hin.
Das Verschieben darf aber nicht so lange dauern. Ich werde dich, sobald ich aus dem Urlaub zurück bin, bitten, mir mal eine Kopie deiner Datenbank zu schicken. Im Moment bitte noch nicht, denn dafür ist meine Internetverbindung via Handy zu langsam.
Hallo Torben,
ich habe jetzt was witziges (oder auch nicht festgestellt)
Folgendes: Neue DB aufgebaut, diesmal ein wenig mehr Mühe gegeben und verschiedene Ordner in der DB angelegt.
Im Vergleich zu der vorherigen DB (gleiche Anzahl Tracks aber alles im Ordner unsortiert) kann ich einen signifikanten Zeitanstieg feststellen.
Wo eine Suche vorher ca. 2 Sekunden gedauert hat ist dies jetzt auf gute 6 Sekunden angestiegen.
Kann das daran liegen das die Dateien jetzt in mehreren DB Ordnern verteilt sind?
Grüße
Nein, die Ordner sind eigentlich egal, die spielen bei der Suche keine Rolle.
Wurde die alte Datenbank mit derselben mAirList-Version erstellt? Oder ist die schon so alt, dass zwischendurch Schema-Updates gemacht worden sind? Meine Vermutung ist, dass bei der neuen irgendein Index fehlt.
Wenn du Lust hast, lad dir doch mal die sqlite3.exe herunter und führe auf beiden Datenbanken den Befehl “.schema” aus und vergleiche die Ausgabe. Besonders auf die Zeilen mit “CREATE INDEX” achten.
Hallo Torben,
werde das mit dem SQLite noch machen.
Was ich dir aber so schon sagen kann. Die “alte” DB, wo alles in unsortiert war wurde am Anfang noch mit dem Schema Null erstellt. Das Schema wurde auf Nummer 7 vor einiger Zeit upgedatet.
Die Neue DB wurde sofort mit dem Schema 7 erstellt.
Also beide gleich und doch unterschiedliche Laufzeiten. Ich werde bei der SAche aber nochmal was prüfen ob da nicht noch was anderes reinspielte in die Geschwindigkeit. Werde es nachher nochmal testen. Zum glück kann man mehrere Instanzen starten 
Nachtrag:
ICh wollte die beiden verschiedenen Versionen jetzt noch einmal in den direkten Vergleich ziehen, was aber grade nicht geht da auch meine alte DB schon auf Schema 7 upgedated wurde.
Alsow erde ich mit der alten 3.0.1 nochmal ne komplete DB anlegen. (Dauert zwar etwas, aber ich will es wissen).
Hallo Torben,
hier mal die ersten Ergebnisse:
Der erste Auszug ist aus der Version welche unter Schema 0 erstellt und auf 7 geupdated wurde (Ich tippe das jetzt von hand da ich zu blöde bin aus dem DOS Fenster nen Copy Paste zu machen)
CREATE INDEX attributes_item ON "item_attributes"(item);
CREATE INDEX item_artists_artist ON item_artists(artist);
CREATE INDEX item_artists_item ON item_artists(item);
CREATE INDEX item_attributes_itemname ON item_attributes(item, name);
CREATE INDEX item_attributes_namevalue ON item_attributes(name, value);
CREATE INDEX item_filenames_storagefilename ON item_filenames(storage, filename);
CREATE INDEX itemfolder_stationfolder ON "item_folder"(station,folder);So, hier der zweite Auszug, welcher direkt mit Schema 7 erstellt wurde.
CREATE INDEX item_artists_artist ON item_artists(artist);
CREATE INDEX item_artists_item ON item_artists(item);
CREATE INDEX item_attributes_itemname ON item_attributes(item, name);
CREATE INDEX item_attributes_namevalue ON item_attributes(name, value);
CREATE INDEX item_filenames_storagefilename ON item_filenames(storage, filename);
CREATE INDEX itemfolder_stationfolder ON "item_folder"(station,folder);Bei der neuen DB fehlt der erste Create Index Eintrag. Habe jetzt extra 3x geschaut, nicht das ich zu blind war.
Grüße
Gut, dann ist vermutlich ein Fehler in meinem Create-Script.
Du kannst den entsprechenden CREATE-INDEX-Befehl einfach mal auf der “neuen” Datenbank ausführen. Wird die Suche dann schneller?
Hiho…
ich erinnere mich mal an einen alten Beitrag von dir wo du sagtest…wo soll das mit den DB Updates mal hinführen wo doch kaum noch jemand einen Kommandointerpreter nutzen kann, geschweige denn die ganzen Befehle kennt. lach
Genauso einer sitzt hier grade.
Ich werde mal versuchen es rauszufinden wie das geht (habe ja schon einen Verdacht) und dir dann berichten.
Habe die ganze Nacht nochmal die gleiche DB mit dem Schema 0 aufgesetzt, so das ich (nach dem einkaufen) mal die beiden Geschwindigkeiten vergleichen kann.
Anschließend werde ich mir von der neuen Schema 7 ne Kopie machen und den neuen Index einfügen.
Ist es egal an welcher Stelle der Index steht oder wie sieht das aus?
Grüße
Peter
Ja, ist egal. Zum Nachrüsten einfach in der sqlite3.exe den CREATE-INDEX-Befehl eintippen/einfügen und abschicken (Semikolon-Befehl am Ende nicht vergessen).
An sich funktioniert der jetzige Schema-Update-Mechanismus ganz gut, finde ich. Der Benutzer kriegt nichts davon mit, was da im Hintergrund passiert. Nur in solchen “Spezialfällen” wie jetzt muss man halt man von Hand ran.
Hm. Ich hab gerade nochmal drüber nachgedacht. Wenn ich es recht bedenke, ist der erste Index
CREATE INDEX attributes_item ON "item_attributes"(item);eigentlich auch total überflüssig, weil er durch einen anderen, nämlich
CREATE INDEX item_attributes_itemname ON item_attributes(item, name);komplett mit abgedeckt wird. (Wenn ich nach item und name suchen kann, dann auch nur nach item.) Wahrscheinlich habe ich ihn deshalb absichtlich gekippt.
Nun würde mich umso mehr interessieren, was deine Geschwindigkeits-Tests ergeben.
Hi Torben,
ok, dann fangen wir mal an:
Es gibt zwei Testreihen und insgesamt vier Tests. Die erste Testreihe (Reihe und Ergbnisse mit “a.)” )sind immer bezogen auf die MaL 3.0.1 Build 544 mit DB Schema 1.
Testreihe 2 und Ergebnisse der Reihe “b.)” beziehen sich immer auf 3.0.6 Build 587 mit DB Schema 7. Die Schematas entsprechen den Indexen aus meinem vorherigen Post.
Die Datenbanken wurden beide mit exakt den gleichen Quellen (also auch ID3 Infos erzeugt).
Test 1: Es wurden zwei MaL Instanzen gestartet
1.) Suchstring “Alphabeat”:
a.) 5 Sekunden mit 18 Ergebnissen
b.) 6 Sekunden mit 36 Ergebnissen…*
2.) Suchstring “Footloose”:
a.) 3 Sekunden mit 8 Ergebnissen (Titel Länge 3:46)
b.) 1 Sekunde mit 10 Ergebnissen (titellänge 3:43) **
3.) Suchstring “The”:
a.) 5 Minuten 4 Sekunden (Keine Systemrückmeldung während dieser Zeit)
b.) 8 Minuten 45 Sekunden (nach 10 Sekunden kam Systemmeldung “Keine Rückmeldung” von Windows)
4.) Suchstring “alabah”
a.) 5 Sekunden bei keinem Ergebnis
b.) 5 Sekunden bei keinem Ergebnis
Test 2: Gleiche Datenbanken, und Suchkriterien, jedoch fahre jetzt nur ein MaL aktiv. A und B haben die gleichen Zuordnungen wie vor:
1a.) 3 Sekunden mit 18 Ergebnissen
1b.) 1 Sekunde mit 36 Ergbnissen
2a.) 2 Sekunden mit 8 Ergebnissen
2b.) 1 Sekunde mit 10 Ergebnissen
3a.) 4 Minuten 50 Sekunden
3b.) 8 Minuten 33 Sekunden
4a.) 5 Sekunden bei keinem Ergebnis
4b.) 5 Sekunden bei keinem Ergebnis
Zwischenergebnis:
Der von mir stark beobachtete Anstieg enstand anscheinend auf folgenden Kriterien:
- Zwei Instanzen von MaL geöffnet (Idee kam aus einem anderen Thread her)
- Aus irgendeinem Grund werden die ID3 Tags anscheinend anders eingelesen. Ich hatte noch weitere Suchkriterien aufgestellt und gemerkt das die DB mit dem Schema 7 fast immer doppelt soviele Einträge hat wie die mit dem Schema 1. Kann es sein das du im Schema 1 beim synchronisieren nur den ID3V1 eingelesen hast, während im Schema 7 auf beide ID3 Tags geschaut wurde? Das wäre eine Erklärung (und ich entsinne mich auch das dies schonmal irgendwo eine Info von dir war)
Test 3:
Um das Problem vom Paul noch einmal aufzugreifen wurde die gleiche Umgebung hergestellt, sprich es wurde Teamviewer aktiviert.
- Bei gleicher Testreihe ergab sich ein zeitlicher Anstieg von einer Sekunde auf allen Kriterien
Test 4: Wie Testreihe 2 jedoch wurde die Prozess Priorität bei jeder Version auf Echtzeit gesetzt:
1a.) 2 Sekunden
1b.) 1 Sekunde
2a.) 2 Sekunden
2b.) 1 Sekunde
3a.) 4 Minuten 40 Sekunden
3b.) 8 Minuten 53 Sekunden
4a.) 2 Sekunden
4b.) 3 Sekunden
Endergebnis:
Die unterschiedlichen Schematas verhalten sich gerechnet, auf die Anzahl der Ergbnisse, gleich. Es gab ja schon mal den Thread wo ich eine ähnliche Laufzeitmessung durchgeführt habe in Zusammenhang mit den Ergebnissen.
Diese Zeiten speigeln sich hier exakt wieder. (Die jetzige Testreihe war noch ein wenig größer, aber das alles zu posten würde glaube ich den Rahmen sprengen und auch keine neuen Ergebnisse liefern)
Der Unterschied ensteht also dadurch das trotz gleicher Quellen zum erstellen der Datenbanken diese unterschiedliche Anzahlen an Ergbnissen liefern.
Aufgefallen ist es jetzt eben dadurch bei mir das ich bei der komplett neuen Erstellung jetzt auch fast alle Einträge doppelt habe (was bei der Erstellung mit Schema 1 nicht der Fall ist).
Somit ist nicht die Suche langsamer geworden, sondern die Anzahl der Ergebnisse höher.
Jetzt stellt sich mir aber folgende Frage: kann man irgendwie unterdrücken das beide ID3 Tags eingelesen werden (Beispiel durch Auswahl ob V1 oder V2 VOR dem einlesen der Dateien, oder das V1 nur genommen wird wenn V2 nicht vorhanden)? Ich vermute dass die unterschiedleiche Ergebnisanzahl hierdurch herbeigeführt wird.
Ich hoffe ich konnte dir hiermit helfen und du kannst wieder ruhiger schlafen lach
Bei weiteren gewünschten test gib mir bitte ne kurze Info.
So, und jetzt werd ich erstmal alles wieder in meinen Ursprungszustand versetzen
Grüße
Peter
Nachtrag zum Test.
habe grade mal anhand der ID rausgefischt wie viele Einträge die DB’s haben.
Die mit dem Schema 1 hat 95679 Einträge.
Die mit dem Schema 7 hat 93072 Einträge.
Wie das zu Stande kommen kann ist mir im Moment noch ein Rätsel, vor allem das der Unterschied so groß ist. Ein paar hätte ich ja gelten lassen…
Oder ich gehe von der falschen Annahme aus das die höchste ID auch gleichzeitig der letzte Eintrag in der DB ist.
Habe grade noch was gefunden was mich stutzig macht.
Aufgrund eines totalen Rechner Absturzes musste ich neu starten. Beim weiterführen der Tests habe ich jetzt unter gleichen Bedingungen festgestellt das die DB in 3.0.6 auf einmal wesentlich schneller ist.
Werde dahingehend auch hier nachher noch einen anderen Test machen.
Ich schicke dir das am besten später per Mail da es eine Excel Tabelle ist.
Grüße
Nachtrag:
Mail ist raus. Ich hoffe es hilft ein wenig. Und wenn es nur ist das man mal sieht was wie lange dauert.
Wow, erstmal danke für die Arbeit, die du dir gemacht hast.
Also um es kurz zu machen, die Versionen sind nicht unterschiedlich schnell, sondern die eine Datenbank ist nur langsamer, weil sie weniger Daten (Attribut-Einträge?) enthält als die andere. Warum das so ist, kann ich nicht sagen. An sich verhalten sich die neueren mAirList-Versionen alle gleich, was den Import von ID3-Tags angeht. (Es gab lediglich einen Bug, aufgrund dessen das Genre zweimal importiert wurde, wenn es sowohl einen ID3v1 als auch einen ID3v2 gab, der ist aber seit Version 3.0.5 behoben.) Die Schemaversion hat auch keinen Einfluss darauf, welche Attribute importiert werden und welche nicht.
Was die Suche angeht, so ist es leider so, dass sie immer relativ langsam sein wird, weil sich der Datenbankserver halt jede einzelne Zeile angucken muss. Einen Index zu benutzen würde nur dann gehen, wenn man die Suche auf “beginnt mit” beschränken würde. Das ist wie beim Telefonbuch, alle Namen, die mit “Ab” anfangen, sind schnell rausgesucht, aber alle, die “ab” enthalten, findet man nur, wenn man alle Einträge durchgeht. Ich schau trotzdem nochmal, ob sich da auf SQL-Ebene irgendwas optimieren lässt.
Da die Suche derzeit aus dem GUI-Thread heraus gestartet wird, hängt dieser solange, bis die Ergebnisse da sind. Es ist leider nicht möglich, die Anfrage vorzeitig abzubrechen und sich nur die Ergebnisse bis dahin anzeigen zu lassen. Der Server liefert immer alles oder gar nichts. Man kann lediglich von vornherein eine Beschränkung von z.B. 100 Treffern festlegen, nach denen die Suche abgebrochen werden soll (LIMIT-Schlüsselwort bei SQL). Daher bleibt nur die Möglichkeit, die Suche in den Hintergrund zu verlegen. Das ist etwas “tricky” zu implementieren, weil man mit mehreren Threads gleichzeitig auf die Datenbank zugreifen muss. Aber es wird schon hinzukriegen sein.
Deine Mail ist übrigens nicht bei mir angekommen.
Hallo Torben,
ich hoffe dein Urlaub war erholsam (meiner auch :)).
Ich sende dir am Montag mal die Datenbankdatei per e-Mail zu.
Liebe Grüße
Paul