Imatch suddenly very slow

[DigPeter]

This might be a temporary anomaly.

I have an Inspiron 13 7000 i7 laptop with SSD and external HDD.  I import from camera into the external HDD for initial processing in IMatch.  This normally works well and quickly.  Today operation was very slow, with activity held up while "reading metadata" which is not set to automatic or instructed to write back.  When I attempted to close the program with a view to restarting, the attached dialog was displayed "waiting for background activity to complete".  This continued for several minutes without closing, so I forced closure through the task manager.  I then re-opened IMatch and it seems now to be reacting normally.

I attach the log, but fear it might not be very helpful, as I had not selected debug logging.

[Mario]

No log attached.
May be related to the database lock issue reported by a few users and which has been hopefully resolved for the upcoming update.
I need the log to tell.

[JohnZeman]

This, or something very similar to this, happens to me too once in a while and it's always when IMatch is reading metadata after I've made some changes to it.

I can walk away from the computer for an hour and when I come back nothing has changed.  So I'll close the database which seems to wake IMatch back up as it finishes database operations which may take a few minutes.  After that I reopen the database and everything works as normal again until the next time it happens.

I haven't submitted a report about this because I haven't quite pinned down what it takes to trigger this problem yet.

[DigPeter]

No log attached.
May be related to the database lock issue reported by a few users and which has been hopefully resolved for the upcoming update.
I need the log to tell.

That is all there was - no actual log.  IMatch operating normally now, so I await the next update - thanks.

[DigPeter]

This, or something very similar to this, happens to me too once in a while and it's always when IMatch is reading metadata after I've made some changes to it.

I can walk away from the computer for an hour and when I come back nothing has changed.  So I'll close the database which seems to wake IMatch back up as it finishes database operations which may take a few minutes.  After that I reopen the database and everything works as normal again until the next time it happens.

I haven't submitted a report about this because I haven't quite pinned down what it takes to trigger this problem yet.

Thanks John.

[Mario]

That is all there was - no actual log.

IMatch always writes a log. Even when it hangs or crashes or whatever.

[claudermilk]

This, or something very similar to this, happens to me too once in a while and it's always when IMatch is reading metadata after I've made some changes to it.

I can walk away from the computer for an hour and when I come back nothing has changed.  So I'll close the database which seems to wake IMatch back up as it finishes database operations which may take a few minutes.  After that I reopen the database and everything works as normal again until the next time it happens.

I haven't submitted a report about this because I haven't quite pinned down what it takes to trigger this problem yet.

Same here recently. I am hitting it pretty heavily with metadata updates (re-keywording, and adding face annotations). My thinking is even with the fast PC (8-core Ryzen), I'm simply outrunning IMatch's ability to process all those database updates I'm throwing at it. Like John, I just stop, tell IMatch to close and wait for it to finish operations. Then re-open and I'm off and running until I get too far ahead again.

[Mario]

If you had log entries starting with ##B or even 'database is locked', these problems should be solved.
I have also shortened the transaction times for data-driven category updates for the next release - this gives better concurrency.