Camera Dashboard

[jack@vankinsbergen.com]

I had to reinstall iMatch5.  I then scanned a folder with new pictures for an existing imatch5 database and discovered that the "Camera dashboard" contained no data, although the data can be displayed via properties of the windows viewer.

Did some option get reset in the re install?  Is there a problem with Exiftool?

jack

[attachment deleted by admin]

[Mario]

Nothing is reset during the install.
Did you check the Metadata Panel in IMatch to see if the metadata of the file was imported correctly?
What about other files?

[jack@vankinsbergen.com]

Mario:

    There does not seem to be any metadata for these files.

    Control+Shift+F5 options return immediately and do nothing.

     The only files that are missing this data are the ones I scanned in since the reinstall.  There seem to be some that  are still stuck in "Updating" mode.  But my CPU usage gadget nor the disk activity light do not show any activity. 

     I just discovered that there are 36 pictures from a month ago still in the "Updating" process as well.  And that is before the reinstall.  See jpg below for four of them.

Jack

[attachment deleted by admin]

[Mario]

Run a diagnosis.
Then selected the pending files and force a rescan using <Shift>+<Ctrl>+<F5>.
Keep the IMatch log file afterwards so we can check for potential ExifTool error messages.

[jack@vankinsbergen.com]

Mario:

   Will do.

    By the way, the reason I did a reinstall was because the the iMatch5 directory was destroyed somehow.   The imatch5.exe file was still present, but it had a zero file size and all the rest of the files were gone.   I can understand that something could have happened to delete files, but also to replace the iMatch5.exe file with a file of zero length?

Jack

[jack@vankinsbergen.com]

Mario:

    Diagnostics ran clean.

    CTRL+SHIFT+F5 doesn't bring up any dialog. And right click does not show the option either. I assume because it is already stuck in "Updating" mode.

    I have attached the log.

Jack

[attachment deleted by admin]

[jack@vankinsbergen.com]

Mario:

    Just found another 36 from the past that are in "Updating" mode.

Jack

[Mario]

This is just the keyboard shortcut for Rescan. The file window must be the active window when you press this shortcut.

Select the files in the file window.
Right-click and choose Rescan from the context menu while holding down <Ctrl>.
This opens the advanced rescan options dialog (see Help for details).
This is also available in the folder context menu.

[jack@vankinsbergen.com]

Mario:

    I  decided to move all the files that were "Updating" to a temp folder.  I discovered that Thirty Six of them were missing files. I removed them and the remaining 36 then completed their "Updating" processing.

   I now have no files in "Update Mode" in this folder hierarchy which contains files dating from Sept 2014.

   However, the most recent 76 files still do not have metadata even after forcing with CTRL+SHIFT+F5. It seems to go through an updating process, but produces nothing.  I restarted iMatch and forced update but still no results.

   i have attached a log file.   It was too big, so I deleted some of the earlier entries.

Jack

[attachment deleted by admin]

[jack@vankinsbergen.com]

Mario:

    Status:

        I created a copy of one of the failing files, and a copy of an older successful file and then forced an unconditional re scan.  There was no Metadata acquired from the two new files or the 76 original failures.  After deleting the missing files documented in the prior post, there are no files showing active updates anymore, and any new files I scan show "updating" activity but produce nothing.

       Are there any parameters that inadvertently could have been reset?

       The ExifTool in the iMatch5 folder is dated 5/28/15 and is 5.17 MB in size.

       There are older copies of Exiftool on the system, but I assume since they are not in the iMatch5 folder they don't matter.

       I loaded two sets of photos into a totally different database. One that had worked properly in the past, and one that fails today.   Neither set produced any metadata in the second database.  So, it would seem that this is not a database issue.

      I have attached the log for the last test.

Jack

[attachment deleted by admin]

[Mario]

This is very mysterious.
IMatch finds and launches ExifTool OK but bone of the methods that need to be ran when importing metadata is ever executed. But there are no error messages or warnings either! Never have seen such an effect. Loading thumbnails, checku-sum generation etc. works as usual.

No other errors or warnings in the section of the log file you have attached (Always better to attach a zipped copy of the complete log file).

You said you "had to reinstall IMatch". Why? How did you install it? What has changed?
Why would ExifTool no longer function on your system?
Was IMatch installed in the same folder before?

[jack@vankinsbergen.com]

Mario:

     As mentioned in a prior post, the iMatch folder mysteriously lost all files except the iMatch5.exe file which had a zero length.  How the files were deleted is beyond me.  But more mysteriously, why would the imatch5.exe file remain with zero length?

    iMatch5 was installed in exactly the same location.  In fact I just ran a "repair" from the installation file a little while ago, with no positive effect.

    I have no idea why Exiftool would fail on my system.  I have been successfully involved with iMatch5 from the beginning .

    I posted some additional info just before I received your most recent reply.

Jack

   

[Mario]

the iMatch folder mysteriously lost all files except the iMatch5.exe file which had a zero length. 

Hum, deleted files. An executable set to zero length. Windows Installer failing to repair the installation?
Sounds like a virus, or an over-ambiguous anti-virus software???

Have you tried to run IMatch while temporarily disabling your virus checker?
Maybe running it as an Admin?

Please see if you can run the ExifTool Command Processor.
Select  a file, then <F9>,<E> or Tools > ExifTool Command Processor.
Choose the "List All Metadata" Preset and run it.
Do you get any output?

[jack@vankinsbergen.com]

Mario:

Just to be clear: Windows Installer does install and repair as required to create a functional iMatch5.  My comment about what it didn't do applies only to the mysterious problem of the missing Metadata.

I have now reinstalled in new directory having uninstalled everything including config parms in C:\ProgramData.

I now have a new problem that prohibits pursuing the missing metadata problem. iMatch5 is hanging constantly for 120000 MS. see log.

A reboot to did not help.

A "repair" did not help.

When I search the forum for "120000", it only finds this post!

It is impossible to continue on the metadata issue (or anything else for that matter) until this performance problem is solved.  For example, just loading the database takes about ten minutes!

I am sure happy that I have delayed installing Windows 10 on this system.  I would be blaming it and wasting my time uninstalling it as a result.

By the way, the Metadata problem still exists even after this total reinstall.

Jack

[attachment deleted by admin]

[Mario]

Please always include the full log file. If you ZIP it you can attach even pretty large log files without modifications.
I use a tool to process log files, and your excerpts prevent me from using this tool for a quick check and analysis.

The log file shows that ExifTool is hanging on every call. IMatch cannot even get the list of supported extensions, which usually takes < 1 second.
Since every call hangs and for every instance, IMatch is blocked completely.

The reason for this is probably the same reason that causes IMatch to import metadata.
My guess would be that you have some sort of security software installed which prevents IMatch from launching the ExifTool Process.
Or that your user account has no permissions or something like that.

If you started all this because, for whatever reason, all files in the IMatch Program Files folder were deleted and the site of the imatch5.exe file was reset to 0 bytes, a security software / virus checker is the most likely cause.

Did you try the ideas I mentioned in my post from last night, about disabling virus checkers etc. closing other apps, trying to run IMatch via the "Run as Administrator" context menu command? I'm pretty sure that this is your virus checker or some other security software interfering badly with your work.

[JohnZeman]

I have no idea if this might be related to Jack's issue but I'll mention it just in case.

Yesterday for the first time ever when I exported new jpg images from Lightroom to IMatch, when IMatch imported those new images it failed to import any metadata from about half of the 200 or so new JPGs it had just imported.  I've never had that happen before over the almost 10 years I've been using IMatch.  To solve my issue I just selected all of the new images, used the keyboard shortcut CTRL+SHIFT+F5, then chose the option to reload all metadata and that time all of the metadata was imported.

Using version 5.4.16

[jack@vankinsbergen.com]

Mario:

    Good morning.

     I had not tried your suggestions, since I was busy dealing with the new issue of performance after reinstalling iMatch5.

     I just started iMatch5 with Admin privilege and Norton disabled.  It is now a couple of minutes into the ten minutes it takes to load the database. 

    This did not fix the performance issue.

Jack

[jack@vankinsbergen.com]

Mario:

    In order to make progress on the original problem, I am now on a different, but slower system that is running Windows 10.   I will get back to the unusable iMatch5 performance  on the other system presently.

    This system also would not initially load the metadata.   I tried to correct some rejected RAW files as well and it went into the interminable "updating" situation on these files.  Log File attached.

    However, the next run was as an administrator with Norton disabled and the metadata appeared.  The interminable RAW file update was still in effect.

    The log file is for the failure with Norton and no admin.  Does it show the failure?  Was it working, just with a delayed effect?  Did the Admin and no Norton make the difference?

    I am running full diagnostic and backup now on the "updated" database on the "working" system.

    I need to now address the iMatch5 performance issue on my main development system.

Jack

[attachment deleted by admin]

[jack@vankinsbergen.com]

Mario:

   I uninstalled and reinstalled iMatch5 with one change.  Instead of installing in "E:\Win 8 - Applications\Graphics\iMatch5" I just took the default "C:\Program Files (x86)\photools.com\IMatch5".

   The performance issue is now gone and so is the metadata issue.   At least with the simple test I ran. I duped a file with Explorer and then re scanned the folder with iMatch5 and the metadata was acquired for the duplicate.

   And no Elevated Admin and Norton is active.

   I have been running with iMatch 3.6 and then iMatch 5 in a custom folder hierarchy for years.  What could have happened to cause all this trouble now?

   Thank you for your continuing responsiveness over the years. It is truly refreshing in the current application (and Microsoft!) support environment!


jack

[Mario]

I have no idea if this might be related to Jack's issue but I'll mention it just in case.

Yesterday for the first time ever when I exported new jpg images from Lightroom to IMatch, when IMatch imported those new images it failed to import any metadata from about half of the 200 or so new JPGs it had just imported.  I've never had that happen before over the almost 10 years I've been using IMatch.  To solve my issue I just selected all of the new images, used the keyboard shortcut CTRL+SHIFT+F5, then chose the option to reload all metadata and that time all of the metadata was imported.

Using version 5.4.16

Did you have a look at the log file?
Maybe LR had the files still locked, thus preventing IMatch/ExifTool from accessing them? That's a frequent issue with LR/PS and their file locking and temporary file usage / 'rename  after write' disk access pattern...

When IMatch notices that something in a folder has changed (it gets a message from Windows), it internally starts a loop which checks every couple of seconds if the file system has 'settled' (no activity anymore for 10 seconds or more in that folder). Then IMatch starts to scan the folder for new and updated files.

This special mode of operation has been designed to deal with applications which first write to a temporary file, then delete the original file and rename the temporary file to the original file name (e.g. Adobe products). It also helps with other RAW processors and audio editors which produce many files in a sequence, e.g. image files and sidecar file updates.

But when an application keeps files locked, IMatch may run into issues when it tries to scan the files. In this case the files remain in the "pending" state and IMatch re-schedules them for a later run.

When ExifTool runs into a locked file, it will block and wait for the file to be released. If this takes longer than a minute (IMatch checks if ExifTool still consumes CPU resources or performs disk access), IMatch considers ExifTool as handing and shuts down the instance, restating a new process. But if the files remain locked, the same will happen...

The log file may include additional details in such rare cases.

[Mario]

Mario:

   I uninstalled and reinstalled iMatch5 with one change.  Instead of installing in "E:\Win 8 - Applications\Graphics\iMatch5" I just took the default "C:\Program Files (x86)\photools.com\IMatch5".

   The performance issue is now gone and so is the metadata issue.   At least with the simple test I ran. I duped a file with Explorer and then re scanned the folder with iMatch5 and the metadata was acquired for the duplicate.

   And no Elevated Admin and Norton is active.

   I have been running with iMatch 3.6 and then iMatch 5 in a custom folder hierarchy for years.  What could have happened to cause all this trouble now?

   Thank you for your continuing responsiveness over the years. It is truly refreshing in the current application (and Microsoft!) support environment!
jack

I have no idea. IMatch is independent from the install location (as you know when you installed it outside the dedicated program files folder in the past).

[jch2103]

I mentioned in a different post https://www.photools.com/community/index.php?topic=4701.0 that Norton flagged my IMatch installation recently after one of its own updates. (I wonder if Norton is more aggressive about 'non-standard' program locations...?) Oddly, I had installed that version of IMatch a week or so earlier without any complaint from Norton. Norton quarantined the IMatch installation but I noticed and reversed it. This was apparently based on Norton's 'reputation' rating, which is strongly biased against new programs that haven't been installed by enough users (I have no idea what constitutes 'enough'). As I said in another post, this is fine for the Adobes of the world, but tough on 'small' developers like Mario... It's possible this is related to the problem you described.

You may also want to exclude IMatch-related activities from Norton scans as Mario has said.

Norton Internet Security (the version I'm sunning) has recently changed their interface; if you're running the same version, you can get to the settings at
- Settings/Detailed Settings: Antivirus/Scans and Risks/Exclusions/Low Risks/Items to exclude from scans (Configure) and
- Settings/Detailed Settings: Antivirus/Scans and Risks/Exclusions/Low Risks/Items to exclude from auto-Protect, SONAR and Download Intelligence
(The new 'simpler' interface makes it harder to find the exclusions settings!)

I've excluded exiftool.exe and the location of my IMatch 5 database.

Glad to hear your main problem is resolved.

[jack@vankinsbergen.com]

JCH2103:

    Thank you for this input.  I have now added my iMatch database and also iMatch program files folder locations to the Norton exclusions.

    It is interesting that I have run for years with my program hierarchy on the E: drive successfully!   I use this approach for two reasons:

    1. Keeps the Windows partition more vanilla.
    2. Much easier to find things.

    I intend to leave iMatch in the default location anyway, as I don't want to deal with potential collateral damage.

    At least the problem didn't just "disappear".  I now have a work around - that is, use the default location. That is why a very basic rule of debugging is  - just change one thing at a time!

    I have been working with computer technology since 1959, in my career - hardware development and then IBM operating system development. 

    In my earliest days we used to call our Philco computers - "confusers" held together by "bailing spit and wire".  This latest problem certainly qualifies!  it makes no sense, as it has been working for years and nothing has changed, at least not externally.  Now if this had happened on one of the systems I recently updated to Windows 10,  there would have been an opportunity to create some undeserved "folklore" as I no doubt would have immediately suspected Windows 10!

    I will chalk it up to your Norton suggestion, and keep that as an arrow in my quiver for the future!

    Thanks, again.

Jack