UI unresponsive running AutoTagger / Exiting multiple times without notice

[bekesizl]

When I run Autotagger with the cloud AIs, the IMatch UI gets unresponsive, rather unusable.
Before my upgrade yesterday with OpenAI "mini" model the UI was still usable as I was using very low request per minute count.

When I start Mistral and Gemini thousands of images with my prompts, I am unable to do anything with IMatch.
The screen get white, mouse pointer is only circling (Windows 11).

I thought, that sending a picture to a cloud service with some text and waiting for a response should not "kill" a one year old laptop with AMD Ryzen 5 7640HS and 32GB RAM.
Before the upgrade I set my machine to balanced or lower.

It is especially a problem, since I would want to start tagging for the images with multiple models, e.g. 500 with OpenAI, 2000 with Mistral and 2000 with Gemini.
Up to now it was possible to start first with OpenAI, I was able to start tagging of the other images and the machine would process them.

I upgraded to 2025.5.5 yesterday evening and started tagging with OpenAI 200 images.
I received a warning that I am not using the service with "enough load", so I check the numbers on the OpenAI page and raised "request/minute".
I also started with many waitings I was able to start Gemini with ca. 2000 images.
I left my machine running for the night.

In the morning my machine was running with IMatch closed, DB temp files open.
I started IMatch again, saved the log. I had to do it multiple times.
Attached here are the logs.

I don't know what I can do here except to reduce the limits for the services.

I was thinking of raising a feature request to be able to pause the processing queue until I add there the files and then start again.
But maybe there is an easier solution.

[Mario]

I just did a test run with 100 images and OpenAI's GPT 4.1 Mini model.
My rate limits: 500 requests per minute, 10,000 RPD, 200,000 TPM etc.
Prompt for description and keywords, AI trait headline.

Did the same with another 100 images using Gemini with the 2.0 Flash Lite model.

IMatch stays responsive all the time, I can easily switch to other Views, run the Renamer etc. 5 year old PC.
AI time between 2.5 second and 5 seconds (response time from OpenAI) and 2s to 32 (Gemini).

Repeated the test on my notebook with similar successful results.
That's enough money spent for today.

The Gemini response times in your log file (imatch_log20250730_0700.txt) is about the same as on my computer.
The OpenAI response time is between 4.5 and 6s on your PC.

Your log file contains many warnings like this:

W> AutoTagger: Aborting because of error [500] 'Timeout.'
W> UpdateQueue (AutoTagger): Service error 500 'Timeout.'

W> UpdateQueue (AutoTagger): Service error 600 (Generic error)

when you are working with Google Gemini. Looks like Gemini was slow and running into timeouts.

I see many calls InnerSearchMB, which is a routine used to search for metadata (e.g. to update data-driven categories), mixed with code that applies Metadata Templates. All in conjunction with calls to AI.

This log file ends with IMatch being idle, doing routine background processing occasionally, reclustering persons, processing some files etc. Looks normal.

In the IMATCH6_LOG_BACKUP_20250730_0604.TXT log file you were working with OpenmAI.
The log file shows an error caused while running a Metadata Template.  I cannot see the name of the template.

Both log files report

#SLOWCAT 'Előhívás'

many times. This must not be a problem.

You were trying to use multiple .MOV files, but AutoTagger could not create a cache images for these MOV files. Which means they are not supported by FFMpeg, e.g. 20220312_073531_iPhone 7_IMG_7972_HEVC.MOV. Probably FFMpeg does not support HEIC movs for patent and licensing issues.

In the OpenAI log file, I see a warning that 93% of the memory are in use. Only 50% of RAM was available when IMatch started.

You are feeding a file named "IMG_7522_IMG7525_panorama.spj" into AutoTagger but it cannot create a thumbnail or cache image. This is not a format IMatch usually imports, at least I could not find the extension in the official file extension list.

The same problem happesn with a number of files with the .exr extension, for which IMatch also has no cache image or thumbnail.

Then you switch to Gemini, which responds with

HTTP Status Code: 503 '[{
  "error": {
    "code": 503,
    "message": "The model is overloaded. Please try again later.",
    "status": "UNAVAILABLE"
  }
}

The last rows in this log file are AutoTagger loading / creating the cache image for the file 06_20120629_Sintra\05\IMG_7975.JPG. Looks perfectly normal.

Summary

+ Gemini AI was overloaded and running into timeouts while you were trying to use it

+ Memory load was very high, almost 95% used.

+ A Metadata Template you apply caused two crashes which IMatch handled internally. What does this template do?
IMatch was busy recalculating data-driven categories, the 'Előhívás', 'Régebben', 'Animal', 'Helyek' and several other categories were reported many times as slow (which must not be bad for a database with 250,000 manages files). There is no free lunch, and the more files you have, the slower data-driven categories become.

+ A good number of unsupported files or files where IMatch failed to create a thumbnail or cache image were pushed into AutoTagger.

Are all these categories visible or do you put these expensive categories under a parent category that has the "Direct assignments only" option enabled? Because when you do that and collapse the parent category, IMatch must not constantly recalculate all these expensive categories.

From experience, when IMatch suddenly closes (is terminated by Windows), but IMatch's internal crash handler is not called, the error happened outside of IMatch. A WIC codec or driver crashed, the system was running out of memory. The maximum memory usage logged by IMatch was 1.5 GB (that's how much memory IMatch used). On a system with 32 GB this is nothing.

Both log files end with IMatch happily doing stuff, either loaded a cache image or running background tasks.
The 3rd log file shows the same "system error / timeout" messages from Google Gemini (overload) and the 4th log file shows nothing unusual at all.

Check the Windows Event log for times around when IMatch was terminated. Sometimes Windows logs useful information there. 

Make sure your virus checker is not interfering.

Maybe your system is somehow overloaded. If you can reproduce this behavior, try reducing the performance profile via Edit menu > Preferences > Application to "Balanced" or even "Low".

[bekesizl]

OK, so it is obviously something with my system/DB.

Virus Checker is defender. Screenshot of exclusions attached.

I deactivated a Metadata template that was running after Autotagger. I haven't used another in the last days.

Moved every formula category and data driven category below a simple category with direct assignments only and collapsed them, also in the Category panel.

I will try to exclude unsupported files and videos.

Big memory use was probably caused by 7z compressing files. It can be avoided.

Windows Event log contains the events of IMatch crashing, but nothing useful to those events.

The performance profile was already set to Low.

The behaviour got better after reorganizing the collections like on the attachment.
But my tests from yesterday evening show, that it is still not easy to anything with IMatch on the UI when the Autotagger is running.
I attached two Debug logs.
I mostly wanted to scroll the screen or change from categories view to the media&folders for test
Also attached a screen of what panels are open.
Do you have any other suggestions what can make IMatch slow?

I have many unconfirmed faces. If that is the cause, can I do something to temporarily disable some face processing?

[Mario]

AutopTagger does not use anything in the UI.
But since AutoTagger updates descriptions, keywords and other tags, categories and collections are invalidated after each image is processed. And AutoTagger processes 8 images in parallel. 

I run AutoTagger with a database than now has almost one million managed files, with all the standard IMatch categories, workflow categories, some data-driven categories  I made for AI trait tags, a metadata template than runs for each file AutoTagger has processed and the whole shebang. This is my mass data and performance test database.

The UI is always responsive, within reason. When IMatch must calculate several expensive data-driven categories to update the screen when I switch from Media & Folders to the Categories View, there is a short pause. But that has nothing to do with AutoTagger.

In the middle screen shot, you have many categories on the top level. IMatch has to calculate each of these visible categories every time categories are in validated, for every place they are visible (Category View, Category Panel, Category Filter, File Window etc.). From a performance standpoint, it is better to place categories under a parent you can collapse when you don't need to see the categories all the time.

Windows Defender rarely gets in the way. I think I recall only one case.
I would not exclude S:\fotok if this is the folder containing your images. A malicious file could be placed there, invading Defender.

The 1914 log has no unusual warnings. Just "sloe" entries for loading the database (15s is a bit slow for a database with only 250K files) and one entry because loading a file window took almost 7 seconds. But many data-driven categories were calculated at the time, so this may be OK.

NOTE: Running IMatch in debug logging is a severe performance drag since no in-memory caching is performed and everything is written directly to disk.

Nothing else is happening in this log file. At least nothing that is slow. No files indexed, no AutoTagger.

The 1950 log file shows AutoTagger running with OpenAI.
The AI time is about 5 seconds (response time). Due to the concurrent workflow with many things happening at the same time (AutoTagger processing up to 8 files in parallel, data-driven categories updated in parallel, etc.) things are really hard to interpret.

Basically I see this:

OpenAI takes 5 to 9 seconds (!) for reach response. Probably their systems were overloaded, as so often.
After each response is received, AutoTagger processes it, stores metadata and keywords etc. This does not even register, which means is is < 5ms. Applying the metadata template takes between 0.1 and 0.25s. All good.

A lot of categories are recalculated (metadata search).

At 19:17:20 this is logged [6078ms #sl] CIMEngineAIAutoTagger::AssignFilesToGroups

AutoTagger tried to assign a file to the "AutoTagger" category. And this took no time before (the longest was 0.1s) and now it suddenly takes 6 seconds! But why?

Between when AutoTagger starts to assign the file to the category and the time it finishes (after 6 seconds) the user interface thread (which runs the IMatch UI) was performing many metadata searches caused by the @MetadataTag category formula. Each search takes about 1 second for your 250,000 files database and AutoTagger had to wait.

This search function uses a cache to reduce database access, but since AutoTagger runs and metadata is updated constantly, the cache is useless and database queries have to be run.

And this gets worse. I see AutoTagger taking (waiting) 7 seconds and more to assign one file to one category. Again, many metadata searches are run in-between by other threads.

I also see a log or metadata and category propagation going on. Do you use versioning and do you AutoTag master files?
Usually, as far as I can tell, propagation takes < 0.2 seconds. But I see outliers like

[10657ms #sl] CIMRelationManager::Propagate, where it once (!) took 10 seconds. At the same time,
[10860ms #sl] PTMDTemplateManager::ApplyTemplate in the same thread. But only once.

My impression is that, on your system and with your database, calculating data-driven and @Metadata formulas brings performance down.

Please check that the "Direct assignments only" option is enabled for both the "IMatch Standard Categories" and the "IMatch Workflow Categories" categories. 

If you have data-driven categories or categories using @Metadata formulas on the top-level (below @All), move them to a parent group, set this group to "direct assignments only" and collapse it.

Disable the option "Assign autotagged files to a category" in your AutoTagger setting. Repeat your test.

Another test would be to make a copy of your database (close IMatch, copy the database file, open that copy) and then remove all categories you don't need. Remove "IMatch Workflow Categories".  Repeat your test.