Mairlist 4 friert ein, ein DB-Problem?

Hab ein neues Thema draus gemacht, weil das Forum das so vorgeschlagen hat :slight_smile:
Aktuell ist es ein 4.4.11, was einfriert. Nicht meines, aber eins von einem Kollegen. Ich bin nur das Technikluder :slight_smile:
Der Kollege kann das Einfrieren einigermaßen reproduzieren, konnte mir das per TV vorführen. Passiert irgendwann wenn man Songs über die Datenbank sucht und vorher mp3-Dateien über den Windows-Explorer sucht, findet, auf den Desktopp kopiert, das vorher die Taskleiste minimierte Mairlist wieder raufholt, von maximiert auf Fenster umstellt, die mp3 in die Playlist “wirft” und dann doch wieder über die Datenbank suche arbeitet.
Der Kollege sagt, daß er den Umweg über den Windows Explorer explizit deshalb macht weil Mairlist bei der Suche per Mairlist-DB öfters einfriert und man auf der Oberfläche nichts mehr machen kann. Blöd , wenn man zu dem Zeitpunkt grad auf Sendung ist. :slight_smile:

Der Kollege hatte eben die Aufgabe, Mairlist einfrieren zu lassen und auf das “frozen” Fenster zu warten. Einfrieren hat er geschafft, aber das Fenster kam auch nach 10min warten nicht. Was machen wir als nächstes?

Es geht bei unseren Leuten generell die Meinung um, daß die Datenbank und die Suche darin über das Browser Fenster Mairlist zum einfrieren bringt. ICH persönlich kann das nicht bestätigen. Angeblich soll die Wahrscheinlichkeit mit der Anzahl der enthaltenen Elemente steigen. Ich will hier keine Diskussion haben ob man 30.000 Songs in der Mairlist DB braucht, ich möcht nur wissen ob Mairlist oder dessen DB eine Obergrenze hat.

Lokale Datenbank? Oder DBClient?

Natürlich dauert die Suche länger, je größer die Datenbank ist. Es gibt aber keine “natürliche Obergrenze”.

[quote=“Torben, post:2, topic:10101”]Lokale Datenbank? Oder DBClient?

Natürlich dauert die Suche länger, je größer die Datenbank ist. Es gibt aber keine “natürliche Obergrenze”.[/quote]lokale DB, Mairlist Home Studio

Ich hol das Thema wieder nach oben, weil es noch nicht geklärt ist. Das Mairlist friert ja immer noch ein. Und eine Info, was man dagegen unternimmt, gab es noch nicht. :frowning:

Es friert nicht ein, es dauert einfach nur sehr lange.

[quote=“Torben, post:5, topic:10101”]Es friert nicht ein, es dauert einfach nur sehr lange.[/quote] Tut mir leid, Torben, aber einen Totalverlust der Bedienbarkeit zuzüglich Stillstand aller Anzeigen (Pegel, Uhrzeiten, Fortschrittsbalken, Restspielzeit usw.) nenne ICH einfrieren! Der gerade aktuell laufende Titel spielt zu Ende, dann ist Ruhe. Man kann nichts mehr machen und muß im Endeffekt das System neu starten. Das ganze ist reproduzierbar.

Dann will ich es präzisieren:

Je kürzer der Suchbegriff, desto länger dauert die Suche, und desto eher erhälst du den Eindruck, die Software sei eingefroren.

Da die Suchfunktion - mit all den verschiedenen Feldern, Attributen, … - eben so komplex ist, kann man das nicht technisch lösen. Lediglich verhindern, dass der Benutzer sehr kurze Suchbegriffe eingibt:

https://www.mairlist.com/forum/index.php?topic=8019.0

Hallo Torben

Stimmt wir verwenden seit langem diesen Code.

[DatabaseSearch] MinChars=3

Wäre es denkbar, wenn es auch ein LimitQuery geben könnte? Gerade bei langsamen Anbindungen (z.B. VPN) an die Datenbank wäre dies von nutzen.

Danke Michel

Ja, steht bereits auf meiner To-Do-Liste.

Kann man die to-do-liste irgenwo liken? 8)

Leider muß ich das Thema wieder hoch holen, zumal sich mittlerweile einiges getan hat. Aber besser geworden ist es NICHT.

Zum einen: Den Eintrag mit MinChars kann ich gern noch vornehmen, der wird aber nichts bringen, denn das Einfrieren passiert NICHT bei der Suche über die Datenbank, sondern sogar schon beim Suchen über Windows Explorer und danach Drag & Drop der MP3 in die Playlist. Der Kollege teilt mir mit, daß heute das Mairlist für ganze 4 Minuten eingefroren ist und nicht mehr bedienbar war. Und dabei hat sich an der Hardware einiges geändert. Wir reden hier mittlerweile über einen 8-Kern-Xeon mit 16GB Ram und SSD-Laufwerken an SataIII-Ports. An der Grafik kann es auch nicht mehr liegen. Windows 7 und Mairlist wurden frisch installiert, Windows durchgepatcht, alle Treiber sind auf dem neuesten Stand und in Mairlist wurde die DB aus vorherigen Installationen übernommen. Auch Layout und Skin wurden übernommen.

Und trotzdem… sobald der Kollege MP3s vom Explorer ins Mairlist wirft, friert das Ding ein. Ich habs per Teamviewer live miterlebt. Und Screenshots machen können. Im eingefrorenen Zustand verschwinden einige Bildschirmobjekte, alle Player und Cartwalls werden quasi weiß und nichts ist mehr bedienbar. Das andere Bild zeigt wie es Sekunden später wieder wie normalerweise aussieht.

Das kann doch so nicht weitergehen…

mAirList selbst braucht sicherlich keine 4 Minuten, um eine Datei von der Platte zu öffnen.

Ist das nur beim Drag&Drop, oder auch wenn man die Datei über das Einfügen-Menü hinzufügt?

Tritt der Fehler auch auf, wenn die Datenbankverbindungen deaktiviert sind? (Selbst wenn man die Datei aus dem Explorer reinzieht, so schaut mAirList doch in den verbundenen Datenbanken nach, ob irgendwo Metadaten zu ihr vorliegen.)

Mir ist mal ein Fall vorgekommen, wo das Öffnen von MP3-Dateien (da aber nur von Netzlaufwerken) Ewigkeiten gedauert hat. Schuld war in diesem Fall ein Virenscanner (ich glaube Norton). Wir mussten dann *.mp3 als Ausnahme hinzufügen.

[quote=“Torben, post:12, topic:10101”]mAirList selbst braucht sicherlich keine 4 Minuten, um eine Datei von der Platte zu öffnen.

Ist das nur beim Drag&Drop, oder auch wenn man die Datei über das Einfügen-Menü hinzufügt?[/quote]Sporadisch und damit kaum reproduzierbar auch abseits von Drag&Drop

Tritt der Fehler auch auf, wenn die Datenbankverbindungen deaktiviert sind? (Selbst wenn man die Datei aus dem Explorer reinzieht, so schaut mAirList doch in den verbundenen Datenbanken nach, ob irgendwo Metadaten zu ihr vorliegen.)
Betrieb wird jetzt mit deaktivierter Datenbank getestet, Ergebnis folgt hier…
Mir ist mal ein Fall vorgekommen, wo das Öffnen von MP3-Dateien (da aber nur von Netzlaufwerken) Ewigkeiten gedauert hat. Schuld war in diesem Fall ein Virenscanner (ich glaube Norton). Wir mussten dann *.mp3 als Ausnahme hinzufügen.
Virenscanner ist nicht drauf, Netzlaufwerke gibt es nicht. Alles lokal.

Also mit DEaktivierter Datenbank (in der Konfig Haken raus) tritt das auch auf.

Nur eine Idee: Sterbende Festplatte? Mal den SMART-Status ausgelesen?

Dann wäre das Problem JETZT immer noch da. Ist es aber derzeit nicht.
Mein Fehler war wohl daß ich mich auf fremde Aussagen verlassen habe. Wir haben ja verschiedene Rechner probiert, aber ob da wirklich Windows frisch installiert war kann jetzt zum Teil ausgeschlossen oder zumindest angezweifelt werden. Offenbar wurden einfach Images von anderen PCs aufgespielt, und die durften sich dann selbst konfigurieren.

Worin GENAU das Problem bestand kann auch nicht mehr nachvollzogen werden.
Ich bin zu dem Kollegen hin…“Format C:” … Windows und alles weitere komplett von vorn installiert… seit Wochen läuft der Kasten.