Strange behavior writing metadata in 5.2.18 (resolved)

Panther · December 13, 2014, 10:41:11 PM

Updated to 5.2.18 today - all seemed to go just fine with the update.

Opened up my database and did a diagnosis (or whatever it's called) and everything reported as OK.

Then I scanned in 4 images and added them to my database folder, and switched over to iMatch to add them in. For some reason, it sat there for about 4 minutes "updating" and "adding new files". I was really getting worried about why it took so long to add just 4 files, but fortunately that only happened the first time, and I've scanned in 3 more sets of 4-6 images each and the speed of adding them has been just fine since that first time.

But, although the speed is now OK, I've noticed something else strange. In the process of adding each small set of image files to the database, I add some simple metadata (author, date created, and a brief description) and assign about 4 categories (all of which are the same for all the files in the set). Then I go to Commands and tell it to write the metadata for all pending files (I have the immediate write-back turned off).

Every time I have done that, iMatch reports that it has one more pending file to write back than I have actually modified in that most recent set. (For example, if I've scanned in and modified 4 files, iMatch tells me there are 5 files pending write-back). I'm not sure if that means anything bad is happening, but it's a little disturbing to see something odd like that.

Any idea what might be going on here? It's not crashing or anything so I don't know if there are any log files or anything that would be helpful to look at.

[edit] - Mario - I'll e-mail the log file I found to you - should be there shortly.

Ferdinand · December 13, 2014, 11:22:56 PM

Without a log file it will be hard to Mario to diagnose what is going on. It's good practice to always attach one, preferably with logging set to debug mode.

Panther · December 14, 2014, 01:02:47 AM

Quote from: Ferdinand on December 13, 2014, 11:22:56 PM
Without a log file it will be hard to Mario to diagnose what is going on. It's good practice to always attach one, preferably with logging set to debug mode.

I know, but I don't have any log files to attach. Is there some way I can make iMatch generate one when it didn't do it on its own?

Lord_Helmchen · December 14, 2014, 01:08:58 AM

IM always generates log files (content depends on selected detail level). You can find it in %TEMP%\IMATCH5_LOG.TXT (usually C:\Users\YOURUSER\AppData\Local\Temp). Open Explorer and type in "%TEMP%".

Panther · December 14, 2014, 03:09:45 AM

Quote from: Lord_Helmchen on December 14, 2014, 01:08:58 AM
IM always generates log files (content depends on selected detail level). You can find it in %TEMP%\IMATCH5_LOG.TXT (usually C:\Users\YOURUSER\AppData\Local\Temp). Open Explorer and type in "%TEMP%".

Thanks - I thought it would have put the log files with the rest of the iMatch files, so I was only searching there. Found the log file just where you said it would be.

Mario · December 14, 2014, 09:21:36 AM

For details about the log file, search the IMatch help index for log file. This explains how to enable the debug mode, how to copy the log file, where to find it etc.

It is preferable to attach the ZIPped log file to your post, because now I have your log file in my inbox, and it may take one or two days until I get by processing your emails (I get between 30 and 50 emails per day). If you attach the log, I can have a quick look right here in the community, and don't need to wade through 100 emails, trying the find the one from you. Saves a lot of time.

Panther · December 15, 2014, 03:04:08 AM

Quote from: Mario on December 14, 2014, 09:21:36 AM
For details about the log file, search the IMatch help index for log file. This explains how to enable the debug mode, how to copy the log file, where to find it etc.

It is preferable to attach the ZIPped log file to your post, because now I have your log file in my inbox, and it may take one or two days until I get by processing your emails (I get between 30 and 50 emails per day). If you attach the log, I can have a quick look right here in the community, and don't need to wade through 100 emails, trying the find the one from you. Saves a lot of time.

Yeah, but this log file contains some personal information/names of particular individuals - not much really and I don't mind you seeing it for troubleshooting purposes but it didn't seem to be a good idea to post it openly on a forum. Hopefully that won't cause too much problem/delay.

Mario · January 01, 2015, 04:57:17 PM

The log file contains many warning like:

Cannot write to off-line/read-only file D:\DB2\...\1940s_...

which means that some of the files IMatch needs to be write-back data to is off-line or read-only or your user account has no write privileges to the files or folders in question. Resolve this problem and see if your original problem persists.

You can, for example:

+ Bring the files reported in the log file on-line and let IMatch write-back, or
+ Solve the file access privilege issue and let IMatch write-back, or
+ Bring the files on-line and force a reload of the metadata to clear their pending write-back state.

Panther · January 01, 2015, 09:15:41 PM

Mario - thanks for looking into this one.

I started trying to do the steps you suggested, when I realized that the warning messages in the log file all seemed to be pointing to the same file, and that file was an .xmp file that had no corresponding .tif file in my database folder. I also noticed that the file in question had an older version of my file naming convention, and seemed to have been orphaned somehow when the associated .tif file was renamed to my new naming convention a few weeks ago.

I deleted that .xmp file via Windows Explorer and tried running iMatch again, but it still reported one phantom file needing metadata re-write. This time the warning messages in the log file were pointing to the associated .tif file (with the same old naming convention), which does not exist (as it had been renamed some time ago). I then told iMatch to rescan my database file folder, and that appeared to resolve the problem. The old/mis-named file is no longer being reported by iMatch as being in my database, and it no longer reports any extra file needing a metadata rewrite when I scan new images in and then command it to write the metadata for all pending files.

I'm not sure how/why the file renaming process got messed up a bit as I was doing all that a few weeks ago, but the problem with the metadata rewrites at least seems to have been resolved.

Thanks for your help.