Imatch seems to freeze when conducting operations on large folders or groups of files. I've observed this with various commands, particularly Delete Rejected Files and Rescan <Folder>. According to Task Manager, Imatch stops responding (for example, during a Delete Rejected process). There's some CPU activity, but it's usually around 0.2%. I've left it open for more than an hour just to see, and it doesn't seem to recover; eventually I terminate Imatch from Task Manager and restart it.
I've followed all of Mario's usual performance suggestions, such as keeping the app and database on separate SSD drives and making sure to exclude Imatch from virus/security software.
It seems doubtful this is a bug, so maybe it's an issue with my database. I've attached my most recent log file and would welcome any insight. Thank you!
The log file ends with an 10010 error/warning: "User Abort".
But the database has only 17,000 files, but IMatch takes a whooping 30 seconds to load this small database and over a minute (!) to initialize the user interface. This is way to slow.
The system reports 4 processor cores and 32GB RAM, which should be plenty.
75% of the available RAM are already used when IMatch starts, which indicates that some memory-hungry applications are running already.
IMatch reports an error with this custom app:
AppManager::Error parsing file 'C:\ProgramData\photools.com\IMatch6\webroot\user\freezeem\app.json': 'default document does not exist.'
Please check that the app is installed properly and contains all the default files (index.html).
Judging by the super-slow load speed, my guess would be that a virus checker or something else is interfering. Or that the system is super-busy, not allowing IMatch to load the database quicker. All file-system operations are extremely slow.
Try making an "exception" for the folder containing the database and the IMatch2025x64.exe executable and see if this changes anything. IMatch being blocked forever during a file system operation is a typical sign of a virus checker misbehaving.