Fehler bei Massenbearbeitung

Hallo,

wenn ich bei meiner Mairlist DB eine Massenbearbeitung mit vielen Einträgen machen will (in diesem Fall um die 37000) bekomme ich reproduzierbar folgen Fehler nach dem das Einlesen fast fertig ist. Natürlich ändert sich der Table Name immer da es wohl temp ist :slight_smile:
Error Massenbearbeitung
wie kann ich den Fehler beheben ?
@ Mairlist Support natürlich habe ich ein Fehlerbericht den ich gerne schicken kann.

Mairlist Version 6.3.16 Windows 10
Ich habe es auch mit dem Aktellen Snapshot probiert man weis ja nie :wink:

Sollteten weitere Infos benötigt werden einfach melden.

Gruß
CoolSpot

Hallo @CoolSpot

hmmm… 37000 Titel in der Massenbearbeitung bearbeiten zu lassen, scheint mir doch zu viel des Guten.

Versuche mal die Anzahl der zubearbeitenden Titel zu reduzieren. Ich hab beim Erstellen der Datenbank und der folgenden Massenbearbeitung immer so um die 1000 Titel markiert und dann bearbeiten lassen.
Dauerte zwar bei guten 20000 Titeln in meiner Datenbank ein Weilchen, aber bei mir gab’s keine Fehlermeldung.

Ich werde heute Nachmittag mal versuchen, das auf meiner privaten Möhre™ nachzustellen. Da dürften auch so ca. 30k+ Titel im großen Musikarchiv liegen.

Es kommt drauf an: Was soll geändert werden und auf was für einer Maschine (Leistungsfähigkeit).
So pauschal würde ich das jetzt erst mal nicht abkanzeln, auch wenn eine stufenweise Vorgehensweise besser zu sein scheint. Es sollte möglich sein, große Datenbestände durchaus über Nacht bearbeiten zu lassen.

Als ich mein gesamtes Musikarchiv neu normalisiert habe (die Lautheit war bereits berechnet), hat das zwar länger gedauert und so hin und wieder tauchte das “frozen-Fenster” auf und verschwand auch wieder, aber so eine Fehlermeldung wie im Screenshot von @CoolSpot ist mir dabei auch noch nicht untergekommen.
Immerhin endet der gesamte Prozess ja dabei und wird nicht im Hintergrund fortgesetzt.

Ich fürchte, da müssen wir bei der Fehlersuche etwas tiefer graben.
Zum Wochenstart versuche ich, Torben etwas Zeit zu klauen (Kinder im Homeschooling wegen Klassen-Quarantäne), aber wenn der bug report Hinweise darauf liefert, dass wir was nachbessern müssen (oder CoolSpot?), dann finden wir das raus.

Gut, dass die bug reports gesichert wurden, das erleichtert die Arbeit erheblich.
Wir kommeen drauf zurück.

Ja, bitte. Und die *.mldb gleich mit dazu.

https://mairlist.com/upload

@UliNobbe so Upload gemacht- Error Log + DB. Bin Gespannt was raus kommt.

@CoolSpot auf was steht bei Dir der Synchronous Modus?

Ich habe den auf FULL, seit wir die Option haben. Bin allerdings trotzdem überwiegend stufenweise vorgegangen in der Massenbearbeitung.

Danke, habe es mir angeschaut.

Der Grund ist wohl, dass du für alle 35k Elemente das Album-Cover als Icon gespeichert hat. Das passt dann, wenn du die Massenbearbeitung anstößt und alle Elementdaten geladen werden müssen, schlichtweg nicht mehr ins RAM.

Überlege dir, ob du die Icons/Cover wirklich in der DB brauchst, oder ob dir nicht die “neue” Methode ausreicht, wo die Playlist sie nochmal on-the-fly aus den Tags ausliest.

Ich habe sie mal testweise gelöscht, deine Datenbankdatei wird dann auch sehr viel kleiner, 38 MB statt 11 GB (nach VACUUM).

3 Likes

Alles klar, ich hatte eh schon vermutet das es sich um ein Ram Problem handelt. OK, wenn sie in der PL auftauchen on the Fly währe das eine Option. Danke !

@shorty.xs da steht natürlich Full drinnen :wink:

Ich muss zugeben, an geladene Album-Cover hatte ich gar nicht gedacht (Vorschussvertrauen?).
Wie auch immer: Nein, das ist nicht mehr aktuell. Bei bestimmten Elementen kann man ja ein eigenes Symbol benutzen, klar, aber ganze Bibliotheken? Nein.

Beim Nachladen einer Playlist kann das ggf. mal ein paar Sekunden dauern (er zieht sich die Cover ja aus den ID3-Tags bzw. Vorbis Comments), aber es spart Speicherplatz, wie Torben bewiesen hat:

KINNERS!!! :flushed:

1 Like

Und danach dann in der Konfiguration, Einstellungen der Datenbankverbindung, unter “Wartung” die Icons löschen und VACUUM ausführen.

1 Like

@Torben Danke. Hatte das schon gefunden und durchgeführt und jetzt ist die DB auch hier “etwas” kleiner :wink:

1 Like

Hallo Torben,
ich kenne VACUUM nicht. Die Google-Suche liefert mir jede Menge Staubsauger, die wohl kaum gemeint sind.
Hättest du bitte Infos für mich oder einen Link, wo ich mich schlau machen kann?

neugierige Grüße
Moni

Das ist ein spezieller Befehl der SQLite-Library, der durch Löschung von Datensätzen freigewordenen Speicherplatz freigibt und dadurch die Größe der Datenbankdatei reduziert. Bei Festplatten hätte man das früher “Defragmentierung” genannt.

https://www.sqlite.org/lang_vacuum.html

Findest du im Konfigurationsprogramm unter Datenbanken → Eigenschaften → Reiter Wartung.

Natürlich nur bei der lokalen mAirListDB; die echten SQL-Server haben andere Mechanismen dafür und erledigen solche Dinge teilweise automatisch.

1 Like

Danke für die schnelle Antwort.
Ich hatte mich schon gefragt, ob es sowas bei der mAirList-DB gibt, denn früher oder später ist es notwendig. Die Wartungsfunktionen hatte ich mir allerdings bisher noch nicht so genau angesehen. Bin ja erst seit Juni letztes Jahr mit mAirList unterwegs :wink: und bisher hat alles wie gewünscht funktioniert. :grinning:

1 Like


:wink: