ACR and the Bridge thumb regeneration problem.

Question

I just installed the 8.4 RC version of ACR to see if it fixed a bug that appeared back in version 7.2. It did not.
The bug appears in Bridge where Bridge randomly and repeatedly regenerates thumbnails. The bug is discussed in several threads on the Adobe Bridge forum. It is a difficult and mysterious bug because it appears to effect only a few people (maybe others don't notice). And those affected report different suspected causes.
Everyone in those threads assume the bug is within Bridge. But in my case, I believe the bug is caused by ACR.
In my version of the bug (Bridge CC on Win7) when I point Bridge at a folder of images, the progress wheel in the bottom left corner will spin and report "xxx thumbnail extractions" while xxx counts down. If I leave that folder and return later (with no changes made to the images) it will regenerate thumbnails and count down again. But not for the entire set of images, just some of them. By "return later" I mean 1 second later.
I've saved proir versions of the "Camera Raw.8bi" file. If I use version 7.1.0.354 of Camera Raw, regeneration of thumbnails ceases. Any version greater than 7.1 causes regeneration.
I have a theory, but ask for help or comment on the likelihood of my theory.
When Bridge scans the images in a folder and compares them to the existing thumbnails in the cache, that comparison has to involve dates. If the date of a thumbnail file is different than the date of the image file, Bridge needs to regenerate the thumbnail.
I don't know what dates Bridge is using to compare cached thumbs to images. I'd guess they are what we see as "Date File Modified".
I don't know where Bridge is getting those dates. Is Bridge getting the dates from the Operating System file management service? Has Bridge stored the thumbnail date in the cache index, and compares it to the image date? Because the regeneration comes and goes depending on the version of ACR, it would seem that Bridge is asking ACR for one of the dates.
All programs display dates in human readable form (Example: 7/15/2013 1:11:50PM). But dates are stored in some other form. I don't know what format is used, but it's probably some floating point format.
My theory is that the dates Bridge uses are in stored in different formats or different precisions of floating point. So, when Bridge compares two such dates they sometimes look unequal when in fact they are the same.
Different CPUs with different math chips might behave differently on critical floating point ops. This would explain why some users suffer the problem while others do not, even if they have the same version of OS.
My knowledge of floating point operations dates back to the IBM mainframes of the 70s. I have no idea how modern CPUs work. I'm hoping someone with current knowledge can comment on my theory. Also hoping the theory reaches Adobe techs, who currently appear to be stumped by this problem.

Answer 1

I found a folder of about 60 images, of which about 80% always repeated extractions, even if changing focus to another application for a couple of seconds.
If I batch-toggled Enable Lens Profile Corrections checkbox on every file in the folder, the repeat extractions stopped. If I toggled them back again, it started again.
This didn't surprise me too much, as the pre 7.3 bug, where repeat extractions occured when active Lens Profiles were combined with touching edge crops (fixed in 8.2), was also Lens Profile related.
Unfortunately, I couldn't isolate the combining factor which causes the repeats in combination with 80% of the files in that folder. Totally stumped.
As ssprengel suggests, it might be date/time-related. I did once notice some weirdness with file system timestamps in the Bridge cache folder. Maybe my 'bad' folder had files with a significant date/time.
Meanwhile, I now disable Lens Profile Corrections by default, which is the factory default setting. I only enable it on some shortlisted images. Repeat extractions a greatly reduced now. YMMV