[GERMAM] iMatch 2023.2.4. plötzlich sehr langsam beim Ändern/Eintragen von Metadaten

[wolboe]

iMatch 2023.2.4. plötzlich sehr langsam beim Ändern/Eintragen von Metadaten
iMatch 2023.2.4. suddenly very slow when changing/entering metadata

Win 10
Datenbank und Datendateien auf gleicher SSD
Aktuelle iMatch Version 2023.2.4.  (am 17.08.2023 installiert)
Ausnahmen von Defender für iMatch- und exiftool- Programmdateien sowie für Ordner der Datenbank erteilt.
Log-Datei angehängt.

Beispiel:
Verzeichnisansicht, Änderung des Eintrages in dc/description wird erst nach mehrern Sekunden im entsprechende Feld des Dateifensterlayouts angezeigt.
Zeit für Schreiben der Metadaten (gelber Stift) dauert bei nur zwei Bilder ca. 5 bis 10 Sekunden.
Änderungen nach der Installation: iMatch-Systemkategorien importiert.
Gibt es Erkenntnisse aus der Log-Datei?


Win 10
Database and data files on same SSD
Current iMatch version 2023.2.4. (installed on 17.08.2023)
Exceptions granted by Defender for iMatch and exiftool programme files as well as for database folders.
Log file attached.
Example:
Directory view, change of entry in dc/description is only displayed after several seconds in the corresponding field of the file window layout.
Time for writing the metadata (yellow pen) takes about 5 to 10 seconds with only two images.
Changes after installation: iMatch system categories imported.
Are there any findings from the log file?

[wolboe]

Sorry, hatte Logatei nicht gezipt!
Problem dadurch?

[Mario]

IMatch meldet viele Male, dass die Datei '0 KEINER KATEGORIE ZUGEORDNET' selbstbezüglich ist.
Die Kategorie hängt von sich selbst ab. Das musst Du beheben.

Dann:

PTMetabase::WriteBack successful for file [151971] 'C:\Eigene Bilder\AAA_neue Bilder\TESTS\parasolpilz_20211019_111114.jpg' in 1 s
PTMetabase::WriteBack successful for file [151970] 'C:\Eigene Bilder\AAA_neue Bilder\TESTS\parasolpilz_20211018_110521.jpg' in 1 s
PTMetabase::WriteBack successful for file [151972] 'C:\Eigene Bilder\AAA_neue Bilder\TESTS\parasolpilz_20211018_110521_3zu4.jpg' in 1 s

PTMetabase::WriteBack for 3 files in 3594ms

Einlesen der Dateien nach dem Schreiben

PTMetabase::ImportFiles ET-Extract for 3 files in 2422 ms

mit ca. 200 Tags pro Datei.

IMatch meldet etwas später #SLOWCAT '0 ENKEL'.
Das bedeutet, dass die Kategorie 0 ENKEL sehr langsam beim Aktualisieren ist. Wie hast Du diese Kategorie aufgebaut?

Ebenso #SLOWCAT 'Nicht kategorisierte Dateien'

Das Aktualisieren der Kategorien und Kollektionen dauert sehr lange und bremst andere Prozesse in IMatch aus.

Arbeitest Du in der Kategorieansicht und hast die IMatch Workflow Categories aufgeklappt?
Oder vielleicht im Kategorie-Panel oder Kategorie-Filter?

Bei einer Datenbank mit weniger als 60,000 Dateien sollten so lange Ausführungszeiten nicht vorkommen.
Das ist, als ob irgendwas auf der Brems seht, sobald IMatch versucht, aus der Datenbank zu lesen oder in die Datenbank zu schreiben.

[wolboe]

Nach längerem erfolglosen Probieren führten schließlich  folgende Schritte zum ,,Lösen der Bremse":
 
Wiederherstellung des Backups vom Vortag (Laufwerk C:, darauf sind  Datenbank und die meisten Bilddateien), anschließend folgende Kategorien gelöscht:
 
·         0 KEINER KATEGORIE ZUGEORDNET
·         0 ENKEL
·         Nicht kategorisierte Dateien
·         Nicht zugewiesene Dateien 
 
Anbei neue Logdatei nach erfolgreicher Reparatur.
Ich weiß nicht, warum es wieder funktioniert - aber Hauptsache, dass es wieder läuft.
Danke Mario - für die richtungsweisenden Tipps
 
After a long period of unsuccessful trying, the following steps finally "released the brakes":
restore the backup from the previous day (drive C:, it contains the database and most of the image files), then deleted the following categories:
·         0 KEINER KATEGORIE ZUGEORDNET
·         0 ENKEL
·         Nicht kategorisierte Dateien
·         Nicht zugewiesene Dateien 
 
Attached is a new log file after a successful repair.
I don't know, why it works again - but the main thing is that it works again.
Thanks Mario - for the trend-setting tips

[Mario]

0 KEINER KATEGORIE ZUGEORDNET 
und
Nicht kategorisierte Dateien 

verwendeten wohl die gleiche Formel und waren daher "von sich selbst abhängig".
Ich vermute das Mal, anhand des Names.

Ich weiß nicht, wie 0 ENKEL aufgebaut war.

"Nicht zugewiesene Dateien" ist eine von IMatch beim Erstellen der Datenbank standardmäßig angelegte Datei und verwendet die Formel "@Unassigned". Sie zeigt alle Dateien, die nicht direkt mindestens einer Kategorie zugewiesen wurden.
Das ist in vielen Fällen hilfreich.

Die "IMatch Workflow-Kategorien" gruppieren Dateien basierend auf Kriterien wie "Kein Titel" oder "Keine GPS-Koordinaten". Sie basieren auf Metadaten-Formeln und sind recht "teuer" beim aktualisieren. Solange "IMatch Workflow-Kategorien" zugeklappt ist, werden sie aber nicht aktualisiert.

Bei einer Datenbank mit nur 60K Dateien sollte das aber nicht wirklich zu irgendwelchen Performance-Problemen führen.
Das Löschen nicht genutzter Kategorien ist aber immer eine Überlegung wert.

Im letzten Log waren aber auch die Kollektionen sehr langsam. Das könnte aber eine Nebenwirkung gewesen sein. Wenn Kategorien beim Aktualisieren die Datenbank für längere Zeit "blockieren", kommen die Kollektionen nicht "dran" und werden langsam. Aber bei lediglich 60K Dateien, sehr merkwürdig...