Hallo Mario!
Ich weiß gar nicht, ob es ein Bug ist oder ein typisches Verhalten wenn man viele mkv-Dateien scannt. Folgende "Auffälligkeiten" habe ich.
Ich erstelle gerade eine Plex-Film-Datenbank. Folgendes läuft parallel ab:
- Erstellung von MKV-Kopien
Konvertierung dieser MKV-Kopien in kleinere Dateien mittels Handbrake
Neue Ordner erkennt IMatch meist gar nicht (selbst wenn das Unterordner sind die MakeMkv erstellt). Erzwungene Updates (Strg+F5) funktioniert meistens, aber das
Hinzufügen und Aktualisieren von Dateien dauert ewig. Alle 20 Minuten lasse ich eine Datenbankdiagnose durchführen. Manchmal findet er Fehler (Verzeichnis).
Ich kenne dieses langsame Verhalten von meinen 4 anderen IMatch-Datenbanken überhaupt nicht, selbst wenn diese wesentlicher größer sind. Liegt das an den MKV-Dateien oder dass die permanent verändert werden (kopiert und geschrieben)? Wäre es sinnvoller diese außerhalb der Datenbank zu erzeugen und dann in Einzelschritten immer wieder neu importieren?
1. IMatch fügt beim normalen Rescan niemals selbständig neue Unterverzeichnisse hinzu, das passiert nur beim manuallen Rescan. Ausnahme, "Advanced file system monitoring" ist aktiv unter Edit > Preferences > Indexing.
2. MKV-Container sind üblicherweise recht groß. Viel größer als Bilder. Da geht automatisch mehr Zeit drauf fürs Indizieren, Berechnen der Prüfsumme und viele andere Funktionen.
QuoteManchmal findet er Fehler (Verzeichnis).
Welche Fehler? Hast du das Diagnose-Logfile noch? Dann bitte zippen und anhängen.
Was ich sehe sind z.B. Meldugen wie "Failed to calculate CRC for file E:\movie-temp\...". Das bedeutet, Match konnte die Datei nicht (ganz) lesen. War sie noch in einer anderen Anwendung offen? Wurde sie noch beschrieben? Windows kann beim Versuch gelockte Dateien zu öffnen schonmal für Sekunden einfrieren und einen Ausführunsfaden von IMatch damit blockieren.
Laut Logfile werden aber viele MKV-Dateien problemlos verarbeitet, in zwischen 2 und 5 Sekunden pro Datei.
Anscheinend werden aber auch einige MKV-Dateien von FFMPEG nicht verarbeitet, was höchst ungewöhnlich ist!
IMatch nutzt dann die Thumbnail-Routine von Windows, die aber auch mit Fehlern abbricht.
Könnte eine kaputte Datei sein, oder ein unbekanntes Format, oder eine Datei, die noch in einer anderen Anwendung geöffnet ist.
Du kannst die fehlerhaften Dateien im Log selbst finden. Einfach nach W> suchen.
Für die weitere Diagnose IMatch bitte auf Debug Logging schalten (Help menu > Support > Debug Logging). Siehe log file (https://www.photools.com/help/imatch/#im_logfile.htm)
Ich glaube das Problem ist, dass die Datenbank dann Schwierigkeiten hat, wenn die Datei erstellt wird (zum Beispiel wenn eine neue Datei konvertiert wird, was ja schon mal trotz AMD 1700 (16 Core) eine Stunde dauern kann). Ich mache diese ganz Sachen jetzt außerhalb von IMatch und kopiere sie erst dann, wenn sie komplett fertig sind in das Verzeichnis, welches IMatch überwacht.
Damit scheinen die Probleme großteils gelöst und Du kannst diesen Thread schließen/löschen. Danke für Deine Hilfe. :)
Wenn Du IMatch laufen läßt wähend eine andere Anwendung ständig neue Dateien anlegt oder aktualisiert, wird IMatch immer das Verzeichnis neu scannen wenn Windows "In diesem Verzeichnis wurde etwas geändert" meldet. IMatch wartet immer ca. 10 Sekunden nach dieser Meldung und führt dann den scan durch. Das gibt den anderen Anwendungen Zeit, die Datei zu schließen usw.
Für den Spezialfall das eine Anwendung eine Stunde lang braucht um eine Datei fertig zu schreiben, hat das Nebeneffekte. Zum Beispiel hängen die Dateisystemfunktionen, die Thumbnailfunktionen in Windows, FFMpeg usw. beim Versuch, die Datei zu lesen.
Einfach IMatch nicht gleichzeitig laufen lassen oder die DB schließen.