Error:too many terms in compound select

Moin ich benutze Version 6.2.4 Build 4149 seit Heute,
beim Auswählen von mehr als 500 Dateien (Massenbearbeitung) bekomme ich den Fehler:Error:too many terms in compound select.
Bei 501 Dateien wird dicht gemacht, in der Vorversion ging es bis 5000 Dateien, und es gab die Fehler Meldung: Out of Memory ( bei 15% Auslastung meines Speichers, belegte Mairlist in der Spitze ca. 1100MB). Die Frage lautet, wo muss ich dran drehen um mehr als 500 Dateien auf einen Schlag bearbeiten zu können, oder ist das in Mairlist festgelegt?
Hätte gerne ein Bild dazu eingefügt… wo geht das hier?

Folgendes habe ich zu dem Fehler gefunden, hoffe das es weiterhilft…:
Eine zusammengesetzte SELECT-Anweisung besteht aus zwei oder mehr SELECT-Anweisungen, die durch die Operatoren UNION, UNION ALL, EXCEPT oder INTERSECT verbunden sind. Wir bezeichnen jede einzelne SELECT-Anweisung innerhalb eines zusammengesetzten SELECT als “Term”.

Der Codegenerator in SQLite verarbeitet zusammengesetzte SELECT-Anweisungen mithilfe eines rekursiven Algorithmus. Um die Größe des Stapels zu begrenzen, begrenzen wir daher die Anzahl der Terme in einem zusammengesetzten SELECT. Die maximale Anzahl von Begriffen ist SQLITE_MAX_COMPOUND_SELECT. Der Standardwert ist 500. Wir halten dies für eine großzügige Zuteilung, da in der Praxis die Anzahl der Begriffe in einer zusammengesetzten Auswahl fast nie mehr als einzelne Stellen beträgt.

Die maximale Anzahl zusammengesetzter SELECT-Terme kann zur Laufzeit mithilfe der Schnittstelle sqlite3_limit (db, SQLITE_LIMIT_COMPOUND_SELECT, size) verringert werden.

Das erklärt warum bei 501 die Fehlermeldung kommt…

Benutzt du eine lokale mAirlistDB oder einen Server mit PostgreSQL?

In letzterem Fall: Bitte den Fehler erneut provozieren und einen bug report senden.
Für die lokale DB haben wir schon einen erzeugt. :sunglasses:

Moin, ich benutze die lokale mairlistDB… in der gui.ini habe ich folgenden Eintrag gefunden:
[DatabaseSearch]
MinChars=0
Limit=-1

das -1 steht wohl für Standard = 500, habe aber keine Ahnung was man da reinschreiben müsste…

Ich bremse deinen Enthusiasmus ja nur ungern, aber da bist du leider auf dem Holzweg.
Die beiden von dir gefundenen Einträge haben mit der Anzahl der Suchergebnisse und der Mindestanzahl an Zeichen für eine Datenbanksuche zu tun.

Du findest sie in der Konfiguration > Verschiedenes > Einstellungen:

Die Standardwerte für beide Einträge sind übrigens = 0; keine Ahnung, wie du auf -1 kommst. :thinking:

Probiere es einfach selber mal aus und schau dir danach mal die Auswirkungen auf den Abschnitt [DatabaseSearch] in der gui.ini an. :wink:

-1 stand da bei mir drin, habe es auf 0 gesetzt, Ergebnis ist das gleiche wie vorher…

Ja. Weil es nichts damit zu tun hat. :wink:

Torben übertrifft sich gerade mal wieder selbst.

Bitte den ganz frischen Snapshot (Build 4150) herunterladen und testen.
https://www.mairlist.com/download/current/mAirList/v6.2/snapshot/

[-] DB: Possible SQL error on Mass Edit in local database (SQLite)

Bei mir sieht’s gut aus.

Danke & Gruß
Uli

Astrein… 10000 files angeklickt geht, kommt zwar einmal “The Aplication seems like frozen”,
da auf Ok geklickt geht. Kann man die Wartezeit bevor mairlist die frozen Meldung auswirft verlängern?
Denke da wartet das Programm nicht lang genug bis die Prozedur durch gelaufen ist, passiert bei mir dauernd wenn ich mit vielen Files arbeite…
Dann muss man nicht immer dabei bleiben, weil die Arbeiten bis zum OK Klick ja in Pause sind…

Nein, sind sie nicht. mAirList arbeitet brav im Hintergrund weiter. Deshalb steht da ja auch „The application seems to be frozen“ und nicht „… is frozen“.
 

Kontinuierliche Grüße

TSD

So ist es. Abwarten und das Fenster verschwindet irgendwann von alleine.

Allerdings ist es in der Tat sinnhaft, nicht zu große Blöcke zur Massenbearbeitung zu wählen. Als ich mal mein Archiv mehrfach in der Massenbearbeitung hatte (aus der Anfangszeit der v6.2 mit der Normalisierung nach EBU R 128), hatte ich das Gefühl, dass es mit Blöcken nicht größer als n.000 Dateien besser klappte als das ganze Archiv auf einmal durchlaufen zu lassen.

Ja, kann man, ist aber nicht im Sinne des Erfinders. Da du aus der Meldung heraus ja einen bug report erzeugen kannst, der speziell aus dieser Fehlersituation heraus geschrieben wird, rate ich davon ab, das Fenster nach hinten heraus zu verschieben.
Umgekehrt wird ein Schuh draus: Manchmal erscheint das Fenster und ist dann aber - weil mAirList im Hintergrund fröhlich weiter arbeitet - schneller wieder weg als man klicken kann. Dann verkürzt man die Wartezeit von der Vorgabe = 60 Sekunden beispielsweise auf 30 und kann so dem Support einen bug report zur gezielten Fehlersuche zur Verfügung stellen.

Letztlich sind das aber eher Ausnahmen, die aus dem bezahlten Support kommen und normalerweise nicht zum Tagesgeschäft von mAirList gehören sollten. Ebensowenig wie eine regelmäßige, große Massenbearbeitung.
Daher mein Vorschlag: Solange es hier nur um ästhetische Aspekte geht und die Arbeit mit dem Programm nicht elementar gestört ist, würde ich an deiner Stelle das Fenster und den Timer in Ruhe lassen.

Anders sähe es aus, wenn das Fenster im Ausspielbetrieb erscheint und währenddessen keine andere Funktion (Mausklick, Tastendruck etc.) mehr möglich ist. Dann bitte noch mal melden, das ist klar.

OK, dann war ich wohl etwas zu ungeduldig, bzw. klicke halt schnell genug auf Ok, das das Fenster von allein zugeht, habe ich noch nicht erlebt… :slight_smile: Teste ich mal… Danke bis hierhin hat sich das Thema dann erst mal erledigt…

Du sollst ja auch nicht das ganze Schnitzel auf einmal essen!

Habe das Schnitzel mal angebissen, bei 18Sekunden Normalisierung pro Track benötigt mein Rechner
34 Tage… bin mal gespannt, seit 2 Stunden läuft es fehlerfrei…:-:wink:

Ups? :flushed:

Das ist… für eine Normalisierung eher lang, selbst auf meiner alten Möhre.
Was in der Tat länger dauern kann, ist die nachträgliche Berechnung der R 128-Lautheit (das ist (noch) nicht die Normalisierung!). Aber trotzdem… 18 Sekunden pro Titel?
:thinking:
Sind das vielleicht 64-minütige Party-Mastermixe oder Disc-at-once-Rips?
Kann ich mir anders gar nicht erklären.

In solchen Fällen bitte wirklich kleinere Blocks in der Massenbearbeitung bilden.

Habe gerade noch mal nachgesehen, sind auch einige Mixe dazwischen, da ich direkt eine ganze Hdd inkl. Unterverzeichnisse angeklickt habe, aber ist halt nicht nur Schlager mit 3 Minuten länge…
ist aber auch runter gegangen auf 5-6 sekunden pro Titel, jetzt ca. 20% (laut Balken).
Da der Rechner eh durchläuft, egal… wenn das in 2 Tagen fertig sein sollte, super…