Thumbnails continually rebuilding

[ycardozo]

I got an update for ACR (CS6) today and installed it. Suddenly, EVERY time I open Bridge or return to it from another page, it starts thumbnailing my images from scratch. We're talking hundreds of images in this folder. This is new. It did not do this yesterday. What is going on and how do I fix it.  If I leave bridge (even if it's still open) and I go back to Bridge, it starts doing the thumbnail extractions all over again and THEN starts on the full size extractions all over again. The result is that all of Photoshop has slowed to a crawl. This is the second time in a month that an update has caused new problems that did not exist before. It's beyond frustrating.

that's cute. I just sat through 10 minutes of full size extractions counting down. it got to zero and STARTED AGAIN. Okay, guys, what's going on? I have 50 gb of images from Asia I need to process. I truly don't have time for this. And the thumbnail extractions just started over again.

Message title was edited by: Brett N

[Yammer]

I don't see a problem with that number, so you'll have to do better than that.

[Guest]

Used 40 NEF files, HQ on demand, generate HQ thumbnail.  Win 7.  Went to different folders, different applications, closed Bridge then opened, no additional extractions on any attempt.  I will be gone for 2 wks so away from desktop.  But will have more raw when I return and can retry.

[Hudechrome]

I just tried it as well. For openers, I do not have an Icon: "Set Bridge to Generate HQ on demand". Second, I do not have: "Generate High Quality Thumbnails" on right click.

I don't know why; I messed with settings in Preferences and saw no appearance of either after closing and re-opening Bridge.

In any case, running the experiment with my settings availability and combinations did not result in any large regeneration effort with a 115 item Collection. I saw one item regenerated quickly, that was all.

So you have a different set of selections than I have.

[ycardozo]

I had the problem with as few as ten images. When I opened a new folder with 10 RAW files that did NOT have any metadata .xmp files, there was no problem. But the minute I added ANY metadata, the problem started again.

[Yammer]

ycardozo wrote:

I had the problem with as few as ten images. When I opened a new folder with 10 RAW files that did NOT have any metadata .xmp files, there was no problem. But the minute I added ANY metadata, the problem started again.

What metadata?

[Yammer]

Hudechrome wrote:

I just tried it as well. For openers, I do not have an Icon: "Set Bridge to Generate HQ on demand". Second, I do not have: "Generate High Quality Thumbnails" on right click.

I don't know why; I messed with settings in Preferences and saw no appearance of either after closing and re-opening Bridge.

In any case, running the experiment with my settings availability and combinations did not result in any large regeneration effort with a 115 item Collection. I saw one item regenerated quickly, that was all.

So you have a different set of selections than I have.

Bridge Path toolbar, Preview generation is 2nd icon on rhs. Options are Prefer Embedded, High Quality on Demand, Always High Quality, and Generate 100% Previews. Select only HQ on Demand. (although I'm not sure this selection is actually necessary to recreate the issue)

If you don't have Generate High Quality Thumbnails on right click, then it's likely your thumbnails are already HQ, as it is context sensitive.

You may need more than 115. Do they have any settings? Which version of ACR are you on?

[ycardozo]

My worflow: I apply my ID/contact info on the first panel (description) after you click file/info. From there, I go to IPTC Extension, where I fill in destination, then I go to Origin, where I fill in destination again. But all I had to do to trigger the recalibration was apply my ID information. I have heard from others that it takes as little as clicking on the stars, tho I don't use this in my workflow. ANYthing that creates an .xmp file will trigger this. As someone else has said, it doesn't recalibrate the entire contents of the folder. But there was absolutely no consistency to what it did in my case. Sometimes it was 40 out of, say 100, sometimes 15, sometimes 35. Whatever. And once it finished, sometimes it started over immediately, sometimes it did not. But if I left the page, the whole stinkng thing started again. Adobe needs to fix this. It should not be us to us to figure it out. It has been reported enough times and we pay way too much for the product for this to not be resolved. When Adobe starts paying me, then maybe I will bring my business to a total halt and start doing their job.

[Yammer]

ycardozo wrote:

It has been reported enough times and we pay way too much for the product for this to not be resolved. When Adobe starts paying me, then maybe I will bring my business to a total halt and start doing their job.

When you say "it has been reported enough times", how do you know? Do you mean these are associates of yours who have contacted Adobe Support directly? And how many times is enough for Adobe? I assume Adobe has some sort of escallation procedure.

As has already been said, this forum is not an official support channel. We are just fellow users who help each other out. VERY occasionally, an Adobe employee pops in, and I'm not aware of anything ever being resolved as a result, but then I couldn't know for certain.

So, if you don't want to help pin this down for a larger number of users, that's fine, don't expect any help in return. If you want to get this problem fixed, bellyaching to us ain't going to do it. You need a better plan.

[ycardozo]

Well, I've asked on the Getty forum if anyone else has had the problem and urged them to call Adobe. I've communicated several times with someone I directly know at Adobe. AND I've called Adobe's tech line. That's all one person can possibly do. SOOOO..... I will ask here directly. Can those of you who have replicated this problem even partially do what I have done...call Adobe's tech line and say something. It doesn't do much good for me to call them again and again. We need more people to call. I guess I assumed others on this forum were calling Adobe. But if you out there have not, please do. And if someone from Adobe sees this, please be aware that many people are discussing the problem and experiencing it.

[Yammer]

I just did another quick experiment with a folder of 60 Raw D800 images which were generating about 30 extractions every time I returned focus to Bridge. I moved the 60 XMP files into a separate directory and repeated the switching to/from Bridge. With the XMP files missing, there were no extractions.

[Hudechrome]

Certainly seems to be an either-or situation. The thing for Adobe to do then, is either obtain one of the bad computers or attempt to replicate the problem and force it into existence. Maybe the better word is model it. The question to ask of a correctly running system is "What do I have to do to the software to make it  do this? What if I wanted it to run that way?"

[Yammer]

Beats me.

One thing I can say is that it's probably not a computer issue. The next folder down my list has 102 Raw images, all with XMP, and there are no extractions when returning focus to Bridge.

[Hudechrome]

It's likely a configuration issue for certain computer setups.

Hopefully it will surface.

[Yammer]

To me, it looks just as random as the old error writing metadata problem, which was fixed by starting again with a new database back-end. The repeating extractions problem seems to be related to the way Bridge deals with metadata. I wouldn't be surprised if this was another Bridge database problem.

[Robert_Shomler]

SG (Adobe staff) wrote in post #102 (December 17): 

"From the details given so far, somehow the Bridge cache for some specific aspect of camera raw files appears to be getting invalidated after it's generated. I've been away to long from the working end of Bridge caching, but hope to get this sorted out.

I'll update this thread as things get figured out."

[Yammer]

Ah. Thanks, Robert. I must have missed that.

[ycardozo]

Much later (specifically early this month), SG let me know that the problem still hasn't been addressed, that he doesn't have time and would try to pass it on to someone else. He has been incredibly helpful but I got the distinct impression that I shouldn't hold my breath.

[Yammer]

ycardozo wrote:

Much later (specifically early this month), SG let me know that the problem still hasn't been addressed, that he doesn't have time and would try to pass it on to someone else. He has been incredibly helpful but I got the distinct impression that I shouldn't hold my breath.

Fingers crossed!

I've just spend half an hour re-reading this entire thread, which is now a BEHEMOTH!

Reading it in one go was very helpful, as I now realise that I've clearly missed some posts, and forgotten others' important observations.

I'd love this bug to be fixed. I think it's actually been around for years, but has become much worse since 7.3 (and nothing in the 7.3 update looks significant). Fortunately for me, I have just upgraded my computer, and it's not such a drain on performance as it was a month ago, but it's clearly still a problem.

As has been observed, it doesn't depend on the camera make/model nor the computer architecture (anyone seen this on a Mac?), but it does seem to happen on specific folders when they contain XMP files. Not all folders are necessarily affected; in my case, most are presently ok, just a few are causing repeat extractions, but my computer was only rebuilt recently, things may get progressively worse with time.

Whenever XMP is created, I assume Bridge must make a copy in its own internal database (indexing). Presumably then, Bridge will check its database against XMP in image folders, and if there is inconsistency it will assume files have changed outside Bridge, forcing an update.

So, it looks like we are totally dependent on a Bridge engineer finding the bug in the source code, fixing it, and issuing an update. Meanwhile none of us has found a workaround that lasts more than a few hours.

One thing I still find strange is that ycardozo seems to be affected much worse than most. If we knew why, it might help narrow things down a bit.

[Yammer]

Yammer P wrote:

Whenever XMP is created, I assume Bridge must make a copy in its own internal database (indexing). Presumably then, Bridge will check its database against XMP in image folders, and if there is inconsistency it will assume files have changed outside Bridge, forcing an update.

So, it looks like we are totally dependent on a Bridge engineer finding the bug in the source code, fixing it, and issuing an update. Meanwhile none of us has found a workaround that lasts more than a few hours.

I tried another simple test:

I quit Bridge

opened up Bridge preferences in regedit

changed the cache location to an empty directory

restarted Bridge

checked for repeat extractions on known problem folders

The result was that previous problem folders are now working okay, although not much is indexed nor cached any more.

I then ran Tools > Cache > Build and Export Cache on a couple of folders — one previously bad, one previously okay

The result was that BOTH folders are now repeat extracting!

[Yammer]

I've just been messing about with the cache. I noticed something strange.

If I manually delete images from the thumbnail cache (256 folder), and let Bridge rebuild the cache, some of the cache files have the wrong date/time created stamp. This only happens to the thumbnail cache, and not the full preview cache (1024 folder).

I just tried the same two folders as previously...

In one folder of 60 images, 52 had the current date/time, 8 had the current date but a time 1 hour 56 minutes earlier!

In the other folder of 102 images, 27 had the current date/time, 26 had a date/time from 2 days ago, 49 had a date/time from 11 days ago.

None of the strange dates match the original photo dates, nor anything in the associated XMP. Where is the date/time created stamp coming from?

[Hudechrome]

Yammer, don't mess with the Bridge gods! People alway try to mess with machine gods, like failing to put thier socks in the washing machine because the gods eat them. (Boy, that makes them mad!)

[Robert_Shomler]

Two important topics run through almost 300 posts in this thread:

1. A presumed bug:  The Bridge cache invalidation problem that can occur when xmp files have been updated both by camera raw (particularly acr 7.3 and 7.4) and some other process that writes metadata to the xmps.

2. A product update functional requirement: the ability to undo an update –an Adobe-supported method to back out a just-applied change that has caused a problem for a user.

Most recent attention is focused on #1, but we shouldn't lose sight of the need for #2.

[ycardozo]

I don't know if I am more affected than others. Thankfully, all it did was just recalibrate. The actual speed of operation of Bridge didn't seem to slow, as it did with at least one other person. But then, I recently had my computer rebuilt and am working with a powerful solid state drive. So basically, all that happened was I saw the folder rebuild and the numbers count down. But the actual function of Bridge didn't seem much affected, thank goodness. It was very unsettling and I half expected things to grind to a halt, though they never did. Since reverting to 7.2, I have had absolutely no problems at all.

[Omke_Oudeman]

(anyone seen this on a Mac?), but it does seem to happen on specific folders when they contain XMP files.

I can't check this for you, while using a Mac I never have run in to this regeneration problem but I primarily use DNG and almost no CR2 with XMP files. Done so for a number of years and reading this thread I don't regret my decision to change my workflow in converting my Canon CR2 to DNG…

[Yammer]

Omke Oudeman wrote:

I can't check this for you, while using a Mac I never have run in to this regeneration problem but I primarily use DNG and almost no CR2 with XMP files. Done so for a number of years and reading this thread I don't regret my decision to change my workflow in converting my Canon CR2 to DNG…

I'm sure I read that it happens with DNG too.