[German] Neue DB - Thumbnails in Verzeichnissen unbrauchbar nach scan

[spiff]

Ich bin mit imatch 2020 jetzt dann am Verzweifeln. Neue DB mit Standardvorgaben (Thumbnails in RAW nutzen, keine Thumbnails aus jpg, RAW Prozess von imatch nicht nutzen Metadaten eingelesen und anschließend automatisch Previews generiert. Das hat sich das ganze Wochenende hingezogen. Alle Verzeichnisse mit RAW und Versionen sehen aus wie in (1) und nach einem normalen rescan wie in (2). Auch die cache Operation bringt keine Bessereung, es sei denn ich nehme den Befehl "Aktualisieren inkl. jpg." - ich will aber keine jpg Voransichten generieren! Die Verzeichnisse selbst zeigen keinen aktualisierungsbedarf an. Nur nach STRG+shift+F5 sieht es so aus wie erwartet. Ich könnte Knochen kotzen, ich habe keine Lust mehr die gesamte DB nochmal zu scannen. Ich sitze hier schon eine ganze Woche dran, endlich habe ich eine DB die wieder funktionsfähig ist und jetzt das. Was läuft hier schief?

[Mario]

Ich kann nicht ganz folgen...

Die Thumbnails werden automatisch generiert, wenn IMatch die Bilder einließt. Das ist komplett unabhängig von den Cache-Einstellugen.
Cache-Bilder werden für den Viewer und das Quick Preview Panel und die Slide Show usw. verwendet.

IMatch generiert standardmäßig (Bearbeiten > Einstellungen > Datenbank) Thumbnails mit 300 pixel Kantenlänge.

Die Thumbails im ersten angehängten Bild sehen unscharf aus.
Und auch größer als 300 Pixel? Das Dateifenster skaliert die Thumbnail hoch, wenn die Thumbnail panels größer als 300 pixel sind und dass kann zu Unschärfen führen - aber nicht so extrem.
Das sieht fast so aus, als konnte IMatch aus den JPEG-Dateien nur das winzige 160x120 Pixel Vorschaubild laden, nicht jedoch das ganze Bild. Dann sind die Thumbs auch entsprechend klein und werden beim Vergrößern super-unscharf.

Aber sowas wird im Logfile immer mit einer W> Warnung protokolliert.
Und kommt auch nur sehr selten vor - eigentlich nur wenn die JPEG-Datei kaputt ist. JPEG macht normalerweise 0 Probleme weil dieses Format von IMatch intern verarbeitet wird und von keinen externen Komponenten abhängt.

1. IMatch auf Debug Logging umschalten (Hilfe > Support > )
2. IMatch neu starte,
3. Ein paar der Problembilder im Dateifenster auswählen
4. Shift+Ctrl+F5 > Force Update.

Logfile dann zippen und anhängen.

IMatch verarbeitet JPEG-Dateien mit ca. 60 bis 200 Dateien pro Minute.
Wie viele Bilder hast Du den verarbeitet, das das ein ganzes Wochenende dauert?

Mach mal ein Screen Shot von den Cache-Einstellungen und häng ihn an.
Auch von allen anderen Einstellungen, an denen Du so rumgebastelt hast. Ich kann mir das alles nicht mehr merken.

[abgestumpft]

Noch als input:
Der Import geschieht ja in zwei Phasen:
1. Reading Metadata
2. Adding and Uploading files

Bei mir sehen die Thumbnails so unscharf wie in deinem Beispiel aus, wenn "1. Reading Metadata" beendet ist, aber "2. Adding and Uploading files" noch nicht.

-> ist aus irgend einem Grund die Phase "2. Adding and Uploading files" evlt nicht getriggert worden, nachdem "1. Reading Metadata" beendet war?

[Mario]

Guter Punkt.

Die Dateien zeigen teilweise noch das blaue "Die Datei wird aktualisiert" und da nutzt IMatch falls vorhanden das niedrig aufgelöste 120 pixel preview in JPG.
Aber wenn die Dateien in der Warteschlange hängen, zeigt IMatch das an und der Nutzer weiß das (Info & Activity Panel, auch in der IMatch Statuszeile).

Wenn die Dateien nicht eingelesen werden konnten weil irgendwas IMatch den Zugriff verwert (der Anwender hat auch viele andere Probleme, die in die gleiche Richtung zielen) sollte ein Nustart von IMatch und dan ein erneutes Einlesen mit Shift+Ctrl+F5 das Problem beheben. Es sei denn, IMatch wird wieder blockiert...

Aber dann sollten viele W> und ggf. E> im Logfile zu sehen sein.

[sinus]

Aber dann sollten viele W> und ggf. E> im Logfile zu sehen sein.

Im Logfile vor einigen Tagen (DB mit 22'000 files / log 52 MB) habe ich rund 350 W> gezählt mit Warnungen wie

ETWARN:Warning: No writable tags set from G:\Eigene Dateien\Eigene Bilder\2019\2019-01-03\20190103_214409.JPG
ETWARN:Warning: Invalid PrintIM header - G:\Eigene Dateien\Eigene Bilder\2003\2003_05_03\20030503_180757.jpg
ETWARN:Warning: Error rebuilding maker notes (may be corrupt) - G:\Eigene Dateien\Eigene Bilder\2003\2003_05_16\20030516_000000_01.jpg
ETWARN:Warning: Error rebuilding maker notes (may be corrupt) - G:\Eigene Dateien\Eigene Bilder\2003\2003_05_16\20030516_000000_02.jpg
ETWARN:Warning: Bad MakerNotes offset for Unknown_0x4c03 - G:/Eigene Dateien/Eigene Bilder/2003/2003_05_16/20030516_000000_04.jpg
...

Keine Ahnung, ob das was zu sagen hat, würde aber darauf hinweisen, dass mit einigen Bildern was nicht stimmt.

[abgestumpft]

Die Dateien zeigen teilweise noch das blaue "Die Datei wird aktualisiert" und da nutzt IMatch falls vorhanden das niedrig aufgelöste 120 pixel preview in JPG.
Aber wenn die Dateien in der Warteschlange hängen, zeigt IMatch das an und der Nutzer weiß das (Info & Activity Panel, auch in der IMatch Statuszeile).

Bei mir kommt das blaue "Die Datei wird aktualisiert"  Symbol auch, wenn ich die Metadaten in die Dateien zurückschreibe, und iMatch direkt danach die Metadaten automatisch nochmals einliest.

Ist evtl. das aktiviert und kollidiert mit dem Einlesen?
Preferences -> Background Processing -> Write-back changes to metadata immediately

[Mario]

Aber dann sollten viele W> und ggf. E> im Logfile zu sehen sein.

Im Logfile vor einigen Tagen (DB mit 22'000 files / log 52 MB) habe ich rund 350 W> gezählt mit Warnungen wie

ETWARN:Warning: No writable tags set from G:\Eigene Dateien\Eigene Bilder\2019\2019-01-03\20190103_214409.JPG
ETWARN:Warning: Invalid PrintIM header - G:\Eigene Dateien\Eigene Bilder\2003\2003_05_03\20030503_180757.jpg
ETWARN:Warning: Error rebuilding maker notes (may be corrupt) - G:\Eigene Dateien\Eigene Bilder\2003\2003_05_16\20030516_000000_01.jpg
ETWARN:Warning: Error rebuilding maker notes (may be corrupt) - G:\Eigene Dateien\Eigene Bilder\2003\2003_05_16\20030516_000000_02.jpg
ETWARN:Warning: Bad MakerNotes offset for Unknown_0x4c03 - G:/Eigene Dateien/Eigene Bilder/2003/2003_05_16/20030516_000000_04.jpg
...

Keine Ahnung, ob das was zu sagen hat, würde aber darauf hinweisen, dass mit einigen Bildern was nicht stimmt.

Defintiv sind einige der Bilder in schlechtem Zustand. Aber das sollte IMatch eigentlich nicht am Einlesen der Bilddatei hindern, es sei denn, die Dateien sind so kaputt, dass IMatch sie nicht lesen kann.
Die Meldungen von ExifTool kommen vom Schreiben und irgendeine Software hat anscheinend ziemlichen Datenmüll in den Bildern hinterlassen. Das ewige Problem mit den propritären "maker notes" der Kamerahersteller. EXIF ist 30 Jahre alter Mist und sollte endlich durch XMP abgelöst werden - aber die Kamerahersteller wollen nicht. Kostet ja was und der Markt wird immer kleiner (dank smart phones). Aber auch aktuelle smart phones schreiben immer noch EXIF-Daten in einem 30 Jahre alten Format... 

[spiff]

Sorry Leute,

ich kann nicht mehr posten, imatch 2020 beginnt mir mein System abzuschießen. Dazu gleich mehr. Vorab, die Bilder wurden aussschließlich immer mit imatch bis einschließlich 2019 gepflegt, gewartet. Es lief immer einwandfrei. Auch die besagten Bilder die seit imatch 2020 im debugg Protokoll auftauchen sind eine Woche und Jahre vorher mit imatch xx-2019 kein Problem gewesen, die DB war immer einwandfrei. Mit Umstieg auf 2020 gingen die Probleme (nach dem Einlesen der Gesichtsinformationen??) los. Wir hatten alles im Verdacht und ich vieles probiert.  Deshalb folgende harte Maßnahmen bisher:
- C formatiert und Windows neu eingespielt
- Neue DB generiert und Metadaten eingelesen
Beim generieren der Thumbnails die geposteten Ansichten ohne irgendwelche Rückmeldung, oder Meldung das Verzeichnisse aktualisiert werden sollen. Wieso schon wieder Strg + shift + F5, das habe ich doch gerade erst angetriggert! Das war doch früher kein Problem in im2019, ein Klick, ein Durchlauf, nach ein paar Stunden zurück an PC und alles gut. Jetzt ständig Probleme bei frischem System und DB schon beim Einlesen der Metadaten an unterschiedlichen Stellen läuft sich 2020 fest. immerhin kann die DB manuell geschlossen werden und nach Neustart von imatch ging das Einlesen dann irgendwann erfolgreich zu Ende, keine Fehler in DB laut Diagnose. Jetzt also das generieren der Thumbnails. Nach diesem merkwürdigen Fehler, aber imatch merkt nicht mal das die Thumbnails nicht ordentlich eingelesen sind, kein Arbeitsfortschritt, Keine Aktion im Info Panel - nichts, habe ich heute Nacht kurzerhand imatch beendet den preview Ordner manuell geleert und imatch wieder gestartet. Imatch fängt an einzulesen und dann läuft urplötzlich der Arbeitsspeicher voll und bevor ich was machen kann schießt mir die Software mein frisches Win 10 64 bit in den abgesicherten Modus, siehe screenshot - so was kenne ich von keiner Software bisher. Diese Software hat einen schwerwiegenden bug! Mein System und alle Hardware läuft ansonsten fehlerfrei.

Ich kann hier aus Zeitgründen leider nicht mehr wie in den vergangen Tagen mitwirken, ich habe jetzt schon mehrere Nächte mit damit um die Ohren gehauen. Ich habe keine Ahnung wie es weitergehen soll, von meiner Seite alles versucht bishe. Ich erwäge mein imatch 2019 wieder aufzupielen, die letzte 2019 DB einzuspielen, keine Gesichtsanmerkungen einlesen und dann müsste es hoffentlich wieder laufe, es sei denn imatch 2020 hat meine Metadaten/ Bilder dermaßen versaut dass auch 2019 ins stolpern kommt. Kann man die 2020 Lizens zurückgeben, oder weiterverkaufen?

EDIT:
Aus der Not mein altes LR4 auf die Verzeichnisse losgelassen, es läuft durch, Import einwandfrei, keine Fehler bisher.

[Mario]

Wenn ExifTool Fehler in den Metadaten von Dateien findest, hat es normalerweise recht.
Das Einlesen von Dateien in Lr kann durchaus klappen. Weil Lr ja nur einen geringen Teil der EXIF-Daten ließt und so gut wie keine maker notes. Du hast vermutlich Lr auch keine Daten Rückschreiben lassen.

Ich wüsste keinen Fall wo ExifTool die Daten in einer Datei kaputt gemacht hätte. Und IMatch nutzt ExifTool seit IMatch 5.
Abgesehen mal von dem Problem mit dem falschen Vorzeichen von GPS-Koodinaten vor einer Weile her. Aber da wurden auch keine Dateien kaputt gemacht.

Lass uns noch mal Deine verschiedenen Probleme aus verschiedenen Threads zusammenfassen:

+ Auf Deinem System meldet das Datenbanksystem in IMatch bei einer sehr kleinen Datenbank oftmals locks und timeouts
+ ExifTool hat regelmäßig Probleme beim Lesen bzw. Schreiben von Dateien bzw. muss von IMatch zwangsweise beendet werden, weil es nicht mehr reagiert
+ Windows meldet häufig das IMatch nicht mehr antwortet - eine Folge von 1 oder zu vielen Instanzen von 2, vermutlich.

Das kann aber nicht an der Gesichtserkennung liegen. Weil die ja nur dann läuft, wenn Du im Dateifenster Dateien auswählst und dann mit Ctrl+M,F eine detektion auslöst. Oder wenn Du im Viewer Gesichter bestätigst.

Die Probleme in Deinen Logfiles kommen aber immer im Zusammenhang mit dem Lesen bzw. Schreiben von Dateien vor. Oder dem Lesen/Schreiben von Daten in der Datenbank.
So was kenne ich im Support eigentlich nur, wenn ein Virenchecker o.ä. gnadenlos dazwischengeht und ExifTool oder IMatch das ausbremst, dass nichts mehr geht.
Hatte gerade wieder so einen Fall wo das Laden einer 200,000 Bilder-Datenbank plötzlich 10 Minuten dauerte und IMatch dauernd hängenblieb. Nach dem Definieren einer Ausnahme in McAffee auf dem Rechner wurde die DB dann wieder in 12 Sekunden geladen und alles läuft rund!
Windows Defender macht aber normalerweise keine Probleme.

In einem anderen Thread (im Feature Request Board obwohl das wohl eher ein Bug Report ist) schreibst Du:

(2) manuelle Vorgabe threads für Metadaten Einlesen (12 threads für 4 Kernsystem)

Das ist viel zu viel für Deinen Rechner. Der hart nur 8 GB und ist vermutlich schon älter. Und Du hast Probleme weil die DB nicht mitkommt.
Du solltest diese Werte auf maximal 2 stellen, um Dein System zu entlasten. Nicht noch viel höher drehen als IMatch das standardmäßig macht. Dadurch verursachst Du genau die Probleme mit Locks usw. die Du beschreibst. Mit 1 oder 2 läuft Dein System vielleicht durch.

IMatch 2020 nutzt eine aktuelle Version des Datenbanksystems und ist auf mehr Durchsatz und bessere Parallelisierung optimiert. Es macht mehr "gleichzeitig" sozusagen. Das ist gut für IMatch.
Normalerweise funktioniert das mit den Standardeinstellungen bestens. Wenn aber bei einer 20K Datenbank schon Timeouts beim Lesen von Daten aus der Datenbank auftreten oder sich Programmteile von IMatch gegenseitig blockieren weil die Datenbank nicht mitkommt ist irgendwas total verkehrt.

Lässt Du IMatch automatisch Daten rückschreiben? Bearbeiten > Einstellungen > Hintergrundverarbeitung? Das sollte AUS sein.

[abgestumpft]

Nochmal etwas input von mir, was ich bei meinen Import Performance Tests festgestellt habe (Mario kann das evtl. bestätigen / korrigieren):

1. Reading Metadata
Die Anzahl konfiguriert in "Threads for metadata import" bestimmt wieviele exiftool.exe prozesse gleichzeitig die Metadaten aus den Dateien lesen. Bei mir laufen diese Prozesse im temp dir unter (d.h. dein entsprechendes verzeichnis evlt. mal im Virusscanner ausschließen):
%TEMP%\par-53656261737469616e\cache-exiftool-11.85\exiftool.exe

Das exiftool schreibt die Daten dann in xmp Dateien in %TEMP% (für jedes Foto eine Datei), die dann von iMatch in die Datenbank eingelesen werden (danach werden sie gelöscht).

D.h. sowohl das %TEMP% Verzeichnis, als auch das Verzeichnis der Datenbank werden beim reading metadata Schritt viel zu tun haben.

Bei mir liegt beides auf c:\ (Samsung SSD 970, NVMe -> schafft knapp 3,3 GByte/sec lesen/schreiben)

Ich hab jetzt gesehen, dass bei einem "Reading Metadata" der "Antimalware Service Executable"->"Windows Defender Antivirus Server" zwar nur 3% CPU hatte, aber beim Datenträger mit ca 100MB/sec dabei war. Evtl nur Zufall, muss das in Zukunft mal beobachten...



2. Adding and Uploading files
Hier nutzt iMatch ja entweder den internen LibRAW oder eben den WIndows eigenen WIC codec. Bei embedded JPG war bei mir die RAM usage meist überschaubar (2GB).
Du scheinst ja das RAW zu konvertieren. Das hat bei mir deutlich mehr RAM gebraucht. Mein Rechner hat 32GB, hier mal meine Notizen vom Test (grobe Hausnummer):
Threads for file import = 8     ca- 20-25GB
Threads for file import = 12   ca. 25 GB
Threads for file import = 16   32GB (100%)


D.h. bei beiden Einstellungen ("Threads for file import" und "Threads for metadata import" würde ich mal mit niedrigen Werten anfangen, und die System Auslastung anschauen.
Am Besten auch die Ordner einen nach dem anderen importieren und nicht alles auf einmal.

[spiff]

Nach dem ich jetzt ein paar Tage die Finger von imatch gelassen habe um den Frust zu verdauen, melde ich mich hiermit zurück.
Bzgl. der Anzahl der Prozesse, das waren nur Versuche mit einer Test DB angefixt durch die Ergebnisse von abgestumpft. An meiner eigentlichen DB arbeitet imatch ausschließlich mit Vorgabewerten "0" für alle Prozesse.
imatch ist zudem so voreingestellt dass es nicht im Hintergrund Metadaten in xmp schreibt.
Es werden die im RAW hinterlegten .jpg genutzt, keine Konvertierung.
Imatch wurde innerhalb der letzten 30 Minuten schon wieder zweimal vom System beendet, ich berichte jetzt dazu wieder im thread: [German] imatch 2020 friert beim Einlesen von Metadaten ein

Björn