Datenbank-Absturz? 
Jep. Interpreten geht ja noch aber “Alles” mag er nicht so… ca. 350 t Titel aber das sollte ja kein Problem darstellen.
Doch, bei einer lokalen Datenbank (SQLite) sehe ich da mögliche Probleme.
350.000 Titel?
Das sind, wohlwollend umgerechnet auf eine Bravo-Hits-Doppel-CD mit mittlerweile 48 Titeln, locker 7.292 Doppel-CDs diesen Typs.
Der Benutzer @calypso60 stößt aktuell auch an gewisse Grenzen (Link), und bei ihm liest sich das so:
Ich trenne diesen Teil der Diskussion gerne in einen neuen Thread ab und dann können wir näher darauf eingehen, was du unter “Absturz” verstehst. Es müsste ja zu einer Fehlermeldung kommen bzw. zum Fenster “The application seems to be frozen”.
Fehlermeldung kommt nicht, das Prog. verabschiedet sich nur kommentarlos. Nun ja, in all den Jahren sammelt sich schon was zusammen…
Nachdem ich jetzt das Zusammenspiel von mAirList und D&R Webstation dank euren ausführlichen Erläuterungen, nochmals recht vielen Dank dafür, hinbekommen hab bin ich nun an der Datenbank. Es dauert ewig bis das Programm startet und wenn ich auf “Alles” klicke braucht er mehr als eine halbe Minute bis der Fehler kommt: Out of memory. Aktuell stürzt das Programm nicht ab aber ich kann es auch nicht mehr nutzen wenn der Fehler da war
Wenn ich auf “Unsortiert” gehe kommt dieser Fehler:
Aus der Fehlermeldung heraus bitte die “Details” klicken (das war schon eine gute Idee) und dann bitte “send bug report”. Danke!
Aber ich habe mir eben überlegt, wenn ich die Datenbank aufteile, die Aufteilung so wie ich die auf dem Server habe, das wird circa 40 Stück geben… dann sollte das doch funktionieren? Die Suchfunktion ermöglicht ja eine globale Suche in allen Datenbanken. Frage: kann ich so viel anlegen oder ist das beschränkt?
Mal ehrilch: Das ist doch Murks.
Ja, sehe ich auch so. Anders währe es mir lieber.
[unk]
Wenn das Programm 350.000 Titel aus einer Datenbank nicht schafft, wie soll es dann soviele Titel aus vierzig verarbeiten?
[/unk]
-
Was für ein Server?
-
Welche 40 Aufteilungen sollen das denn sein?
Das tut sie. Weil ich damit übergreifend verschiedene Datenbankzugriffe nutzen kann, z.B. lokal und externe als Client.
Daraus jedoch den Grund für 40 Datenbanken abzuleiten, erscheint “kreativ”.
Du kannst doch die jeweiligen Speicherorte anlegen.
Als ich die Musik einlesen wollte konnte ich nur in “Unsortiert” einlesen und diesen Ordner nicht ändern.
Ich habe natürlich verschieden Ordner angelegt und dort erscheinen die Titel auch, genau so wie sie auf dem (heuseigenen) Server zu finden sind. Ich greife über das Netzwerk auf die Dateien zu.
Nur eine Frage: Wo befindet sich die mldb-Datei, also die Datenbankdatei?
Auf C:\ProgramData\mAirList\7.x\
Meine Datenbank enthält derzeit zwar nur rund 215-tausend Datensätze. Aber, wie Uli ja schon eingestreut hatte, auch ich beobachte Performanceschwächen. Einen Komplettabsturz hatte ich allerdings dabei noch nicht. Leidglich lange Wartezeiten mit immer wieder auftauchenden „seems to be frozen“-Meldungen. Auch erscheint öfter in der Kopfzeile „Anwendung reagiert nicht“.
Konkrete Zahlen dazu hatte ich mal gestoppt:
Gleichzeitig ist aber die reine Suche nach Titeln oder Interpreten sehr schnell. Sie liegt bei mir im Bereich von 1 bis 3 Sekunden. Nimmt man die Suche in Attributen dazu, dauert es natürlich länger.
Nun frage ich mich, wozu die Anzeige „Alles“ überhaupt nützlich sein könnte? Ich habe sie bisher eigentlich nur dazu benutzt, um die Anzahl der Datensätze zu ermitteln. Ansonsten sucht man ja eher nach Teilmengen, was prinzipiell mehr oder weniger schnell funktioniert.
Aus meiner Sicht würde es bei „langatmigen“ Suchen schon sehr helfen, wenn dem Anwender eine Art Fortschrittsbalken angezeigt würde. Bei mir verliert Software immer an Vertrauen, wenn sich „nichts mehr sichtbar tut“. Kommen dann noch Fehlermeldungen dazu, schwindet noch mehr Vertrauen. So ist es ja auch bei Massenbearbeitungen. Man sieht oft nichts von irgendeinem Fortschritt. Deshalb finde ich wünschenswert, dass mAirList da „kommunikativer“ würde.
Und bei dieser Gelegenheit möchte ich auch noch einmal für „dynamische Ordner“ plädieren anstelle oder in Ergänzung der virtuellen Ordner. Ich meine damit Ordner, die Titel nach bestimmten Filtern auflisten. Solche Filter gibt es schon beim Scheduling. Vielleicht könnte man das auch auf solche Handsuch-Ordner übertragen.
Für mich ist es sinnlos, z.B. deutsche, von Männern gesungene und zwischen 1974 und 1978 entstandene Titel von Hand in einen virtuellen Ordner zu schieben. Denn dann muss ich ja nach einer Woche oder einem Monat, wenn wieder 500 Titel dazugekommen sind, schon wieder mit der Schieberei anfangen. Wozu? Das soll doch die Software machen.
Und zum Abschluss noch eine Vergleichszahl aus der d’accord librarie:
Anzeigen von 10-tausend Datensätzen dauerte 2 Minuten und 18 Sekunden. Suche nach 288 Abba-Titeln dauerte ca. 8 Sekunden.
Da ist mAirList schneller 
1 Like
Ich habe eben das Update eingespielt. Die Datenbank starten dauert 3 Sek, einen Ordner in “Speicherorte” mit ca. 170.000 Titeln zu öffnen gut 15 Sek. Nach “a. v. A.” (alles von ABBA ;-)) suchen in mAirList geht sehr zügig! Allerdings stürzt die DB wieder ohne Fehlermeldung ab wenn ich “Alles” anklicke. Ich werde mal um 150 t Titel auslagern, mal sehen ob es dann besser funktioniert.
In einigen Bereichen sind ja schon Fortschrittsanzeigen hinzugekommen. Ob Torben das auch in die Suche einbauen kann und möchte? Ich nehme es mal in die Wunschliste auf.
Richtig, bei der Playlist-Erstellung haben wir schon sehr umfangreiche Filter-Möglichkeiten. Und den von dir beschriebenen dynamischen Ordner kenne ich von iTunes. Sie nennen das dort “Intelligente Playlist”, glaube ich.
Auch das erweitert die mAirList-Wunschliste (Torben wird mit mir nach den Ferien und seinem Urlaub ein Personalgespräch führen müssen 
).
Das ist schon mal gut und richtig und eine Fehlerquelle weniger.
Wem ist das auch so ergangen bzw. kann das nachvollziehen?
Mal interessehalber: Wie groß ist denn bei Dir die Datenbank-Datei in MB?
Ich habe übrigens einen signifikanten Geschwindigkeitszuwachs bemerkt, nachdem ich alle Cover aus der Datenbank gelöscht habe.
Die SQL-Datenbank ist von 980 MB auf 27 MB geschrumpft (wäre vielleicht gut, wenn die “Icons” nicht in der dB, sondern in einem Ordner der Festplatte gespeichert werden könnten).
Nach dem Löschen der Cover geht alles sehr fix…
Falls jemand fragt: Doppelklick auf Datenbank und hier löschen…
Das wird von uns grundsätzlich empfohlen. Auch calypso60 hatte diesen Aha-Effekt.
Sofern die Cover Bestandteil des ID3-Tags sind bzw. Vorbis Comment, liest mAirList sie direkt dort aus, wenn das Element in die Playlist geladen wird. Ist eine Option der Playlist. Ein separater Ordner ist zu diesem Zweck meines Erachtens nicht nötig.
Allerdings scheint es in der dB-App anders zu sein. 
Warum sonst dauerte es mit Covern deutlich länger, eine große Anzahl Datensätze zu laden? Es fühlte sich an, als wenn dann vor dem Anzeigen erstmal alle Daten inklusive Icons übertragen wurden. Eine Massenbearbeitung zu einer Datenbank im Internet war auch nur bis zu rund 3500 Titeln möglich, sonst stürzte mAirlist ab… Ohne Cover kann ich nun alle 90.000 Elemente bearbeiten…
Und wenn man schon die Dateien lokal spiegeln kann, wäre es auch sinnvoll, das selbe mit den Covern machen zu können. Denn auch das Öffnen des Editors dauerte bei Verbindung per dB-Server mit Covern deutlich länger als ohne…