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]

Omke Oudeman wrote:

Since I make a habit of regularly dumping the complete cache I have no problem with this but I can imagine you think otherwise

However, when needing to recache I do often so overnight, using the main folder and the option to show content from subfolders, ending up with a freshly new cache for the lot.

I did that on Monday, as a precaution, after rolling back to Camera Raw 7.0. It took most of the day to regenerate a 23GB cache. I dumped the Camera Raw cache too.

I had been running all of my disk caches on a RAID, but I discovered recently that it was under-performing (it never rains, it pours), and so decided to move them back to their default locations. I thought this might also discount any chance that I may be causing operational problems with non-standard cache locations.

[Hudechrome]

I have several Collections already, and yes, after a bootup, Collections takes time to regenerate, <10sec for 60 images. But, subsequent opening  the file is just as quick as the file itself at the root location. And root kocation did not require any regen. So my conclusion is that at root, no regen. At Collections, the pointer has to reset.

If Adobe has been able to generate the error, it ould be interesting to know how that came about...departures from a stanard computer for starters.

[Omke_Oudeman]

I had been running all of my disk caches on a RAID, but I discovered recently that it was under-performing (it never rains, it pours),

As we are here covered in a bit of snow I'm happy to say rain is not bothering me at the moment (knock knock on wood...)

Personally I never have seen the benefit of using a RAID system. It is a very expensive way of storing files. On a Mac you need also an expensive RAID card and e.g. having a total capacity of 5 TB of disk space good quality RAID only let's you use half of it effectively.

I have bought a 4 port eSATA PCI slot (much cheaper then RAID) and a four bay eSATA hot swappable disk unit (very cheap, StarTech.com) and use a bunch of internal disks of 2 TB with a proper back up scheme. Having also the benefit of the possibility to store the second back up on a different location

[Yammer]

I had trouble understanding your post. What do you mean by "root"?

Even if I allow the computer to "catch up" after loading a Collection or a Search, if I then proceed to work on the images (including opening in Camera Raw, keyword, removing, or deleting), Bridge will just decide to start extracting more thumbnails and/or regenerating more thumbnails/previews (even if they don't need it) again.

I guess there's a practical limit to the number of images you can work on in a collection or search (i.e. a temporary group of images in different folders).

I think part of the problem lies in the nature of Bridge's design. I have noticed that Bridge never stands still, and is constantly looking for changes to the file system. SysInternals' Process Monitor shows Bridge polling several drives every few seconds. I thought that maybe there was something going on in my computer which was mistakenly being detected as change. But I've reinstalled Windows and changed computer and software several times since I first noticed this, so I'm less inclined to believe it any more.

Edit: the implication of this activity is that it makes browsing and editing images and metadata painfully slow—which is frustrating when the activity is unnecessary in the first place.

[Yammer]

Omke Oudeman wrote:

Personally I never have seen the benefit of using a RAID system. It is a very expensive way of storing files. On a Mac you need also an expensive RAID card and e.g. having a total capacity of 5 TB of disk space good quality RAID only let's you use half of it effectively.

When I first installed the RAID, all I did was buy three fairly fast (110MB/s) but cheap 500GB WD Caviar drives. This gave me a total 1TB of 220MB/s storage (RAID 5). As they say in these parts, I was chuffed to bits.

A year later, one of the drives failed, and was replaced FOC by WD. A couple of weeks ago, when I was struggling with performance, I noticed the RAID performance had dropped to 170MB/s, and worked out that the replacement was to blame. WD are still dragging their feet over this. Presumably it would be easier for them if it just died, or I died.

[Hudechrome]

I had trouble understanding your post. What do you mean by "root"?

The root folder is where I d/l the images. They are distributed among several drives, but mostly on the Edit drive. When I create a collection, I might want to reference the final print or maybe the RAW as well, so Collections can be generated from several drives/locations. But Collections itself is on C drive.

Even if I allow the computer to "catch up" after loading a Collection or a Search, if I then proceed to work on the images (including opening in Camera Raw, keyword, removing, or deleting), Bridge will just decide to start extracting more thumbnails and/or regenerating more thumbnails/previews (even if they don't need it) again.

I don't know what you mean by "more". I just opened a file in ACR, tweaked it a bit, saved it and yes, the regen did take place, momentarily, but that is expected, no?

I saw no evidence of any other thumb being regenerated.

So, at least on some systems (Camera to Computer to OS to App) the problem doesn't show up, the problem being all thumbs regenerate, as I understand the presentation here.

[Hudechrome]

Presumably it would be easier for them if it just died, or I died.

LOL!

I think that is generally true for many tech support centers. If not die, at least steal away into the night.

[Omke_Oudeman]

Presumably it would be easier for them if it just died, or I died.

I would say that it would be easier for both if you just quit Raid and started with normal use of HD and back up scheme.

Although this would not be directly the cheapest way for you but since living is expensive you probably would not spot the difference in your wallet anyway...

[Omke_Oudeman]

They are distributed among several drives, but mostly on the Edit drive.

As a Mac user I don't understand much of your alphabetic disc usage but I do know for a fact that Bridge is not good in multitasking and also not know for its speed. Having spread files over multi disks is possible as advertised by Bridge because you can browse them in the folder panel.

However collections are in normal state from one disk not very stable nor very trustable, let alone collections spread over different disks. Personal I would not rely on collections and since removing files from a collection also needs to be handled with care (easy to delete the original also) I only use collections limited.

First I place all the files needed as the base to create a collection from in one folder and then use the collection only to use in Mini Bridge on a project in PS (creating a photo album). Since they screwed up MB in CS6 this is not an easy task anymore but I manage.

[Guest]

Omke Oudeman wrote:

Having spread files over multi disks is possible as advertised by Bridge because you can browse them in the folder panel.

Not sure what this means on a Mac.  On Windows a disk is considered a partition or another physical drive.  With Bridge you can not search across different disks so that does limit how you place files.

[Yammer]

Hudechrome wrote:

...

But Collections itself is on C drive.

Even if I allow the computer to "catch up" after loading a Collection or a Search, if I then proceed to work on the images (including opening in Camera Raw, keyword, removing, or deleting), Bridge will just decide to start extracting more thumbnails and/or regenerating more thumbnails/previews (even if they don't need it) again.

I don't know what you mean by "more". I just opened a file in ACR, tweaked it a bit, saved it and yes, the regen did take place, momentarily, but that is expected, no?

On Windows, Collections are stored as files on the boot drive, but these files are just XML lists of the source files, which could be anywhere. At the moment, my working project collection of 6200 raw files is 464 kB. The others are about 50 kB. I appreciate that this is probably quite big, and not quite what the Bridge engineers had in mind. But no one ever told me I couldn't do it

What I mean by "more" is that, even if I only update say 5 images, Bridge will say that it's generating thumbnails/previews for substantially more than 5 images. This is despite all of my images already being cached and indexed (and with the maximum cache size set in preferences).

One thing I have noticed latterly is the large number of thumbnail extractions every time I do virtually anything in Bridge. Even if I follow this thread, or read my emails, as soon as I return to where I left Bridge, it starts thumbnail extractions again.

(Having said all this, I can't seem to get the thumbnail/preview generation thing to happen today. It's been a long day, and my head is in bits, so I'll have to get back to you on a test scenario. With any luck, it's gone away, but I somehow doubt it)

[Hudechrome]

Bridge is a browser. LR a database. So running Bridge like a database will trip one up, likewise using LR as a browser. I wasn't going to use Collections but I gave it a try, and so long as you use "Remove from Collections" button doesn't disturb the originals. In any case, I run backup using a batch file before messing with moving stuff around.

If LR was just a DB, I would use it. All that is necessary is that Bridge and LR talk together.

They don't.

[Omke_Oudeman]

On Windows a disk is considered a partition or another physical drive. With Bridge you can not search across different disks so that does limit how you place files.

No not search but browse, I have a MacPro with 4 internal disks but I can only search in one disk because I cannot choose the computer itself as source. But I can see all the disks, including the external ones in the folder panel, assuming that this is also possible in Windows.

But I have no need for searching in multiple disks, I like to keep it close, my ongoing projects as well as the Raw material form half a year and finished files of the past year are on the same disk (2 TB) together with my system, applications and cache files. This is where Bridge comes at hand.

My central archive is on another disk and both disks have extra back ups. If I need to search I use my dedicated DAM application Canto Cumulus that is also on my main disk with Bridge. My Canto Catalog has a cache file generated from the second disk. This cache file (only 2,5 GB from 60.000 files cached) is also on my main system disk.

Yet double click on the thumbnails of the found files in Canto (active on my main system disk) opens the original files from the other disk in Photoshop without problems

[ycardozo]

I just got another prompt for that update of bridge 5.02. I'm assuming it's the same one I got before and I am also guessing that the smart thing at this point is for me to skip it. Steve, any further, updated info or thoughts on the whole update/RAW/rebuilding/whatever situation?

[ycardozo]

Has anything new been resolved with the problem of continuous rebuilding of thumbnails. I am using a Canon 7D and it only happens when working in Camera Raw 7.3 when metadata is applied to a raw image. I have asked about upgrades to fix this problem but so far have not heard any answers. I had to revert to version 7.2 but that is not a good permanent solution if I want to buy a new camera.

[ssprengel]

Have you tried the ACR 7.4 release candidate from http://labs.adobe.com/

Before installing it, find and save your existing 7.2 plug-ins. I assume you know how to do this since you have already reverted from 7.3 to 7.2.

[Guest]

Are the thumbnails continuous rebuilding, or are you changing the folder before they have completed building?  The spinning arrow in the lower left corner has to stop for the cache to be completed.  If you have HQ thumbnails and 100% previews check that process can take an hour for 800 raw images.  I have heard that each new ACR adds to this build process.

[ycardozo]

yes, they are continuously rebuilding. no, i am not leaving the page early. this happens even if it's only a dozen images. it is somehow connected to creating .xmp files...in other words, adding metadata in RAW. the spinning circle never stops. and no, i am not aware of a 7.4 upgrade. BUT when I had to replace the plugin file....not only could i not do it myself but it took an adobe tech to actually find it for me and do it remotely for me since it is no longer put up publically. I struggled for four days and simply was not able to successfully replace the file. I do NOT want to go through that again. And I am hoping the same adobe tech person who was trying to work this out will get back to me to tell me if the problem has been solved.

[Robert_Shomler]

ycardozo wrote:

Has anything new been resolved with the problem of continuous rebuilding of thumbnails. I am using a Canon 7D and it only happens when working in Camera Raw 7.3 when metadata is applied to a raw image. I have asked about upgrades to fix this problem but so far have not heard any answers. I had to revert to version 7.2 but that is not a good permanent solution if I want to buy a new camera.

One of my cameras is a Canon 7D.  I encountered problem intermittently (only is some folders) with acr 7.3.  Reverted to 7.2 and extensive unnecessary recaching was substantially reduced (but not completely eliminated). 

Posts 35 & 39 spoke to the problem occurring after calling File Info from within Bridge.  In post 102 (Dec 17) an Adobe staff person wrote “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.” and in post 156 - January 23 you mentioned that “Someone at Adobe has been able to recreate the problem.”  Adobe updater does not find any Bridge updates - last one was before January 23 - so I would guess that there has been no release of an update to Bridge

I am working now with acr 7.4 release candidate and have not yet encountered a Bridge recaching problem, even after calling File Info from Bridge.  Perhaps the conflict was eliminated in 7.4?  (I have not performed a lot of testing, and I may not have the same system configs, image, or metadata components that caused the problem to appear with 7.3.)

[ycardozo]

I am guessing 7.4 is in beta format now? I will wait till they do the actual release and pray since I wasn't able to replace the .8bi file on my own and by this time, can't even remember the steps. can you (robert) list the steps again for me. I will save them for the future

[Robert_Shomler]

ycardozo wrote:

I am guessing 7.4 is in beta format now? I will wait till they do the actual release and pray since I wasn't able to replace the .8bi file on my own and by this time, can't even remember the steps. can you (robert) list the steps again for me. I will save them for the future

Save your current (7.2) .8bi files (two files, one f or 64-bit, one for 32-bit).  I copy them to a documents folder for that acr version; for example: folder name <acr72> then in two folders in that folder <acr72/64-bit> and <acr72/32-bit>.

The 64-bit .8bi file is in

C:\Program Files\Common Files\Adobe\Plug-Ins\CS6\File Formats

The 32-bit .8bi file is in

C:\Program Files (x86)\Common Files\Adobe\Plug-Ins\CS6\File Formats

After you install 7.4, save the new 7.4  .8bi files in another folder pair such as <acr74/64-bit> and <acr74/32-bit>.   Then should you want to revert to 7.2 you can copy your saved 7.2 files from <acr72/64-bit> and <acr72/32-bit> into the above listed Program Files and Program Files (x86) folders.

[ycardozo]

Posts 35 and 39 and back in January still didn't address whether the problem had been fixed. I know tech guys from Adobe read this site. Steve G or anyone from Adobe....HAS THIS PROBLEM BEEN FIXED??? I was not able to revert from 7.3 back to 7.2 without someone from Adobe taking control of my computer. The mess brought my business to a complete standstill for days. I do not have that technical ability on my own nor do I know anyone who does.  I do NOT want to do any upgrade until I hear whether this has actually been fixed. And yet, I should be able to use this program to its fullest. Bringing up an interesting thought...if Adobe forces everyone to the cloud and such a bug occurs and you have no control over upgrades, WHAT THEN? Is a person just supposed to live with some horrible conflict? Disconnect from the internet? What????? And yes, I am getting somewhat peeved about this entire situation. The initial problem popped up with ACR 7.3 back in November. Here it is 2/3 the way through March ... and still......

[Yammer]

I don't think you can rely on anyone from Adobe reading this. They hardly ever reply to posts. I suppose they could be lurking, but I think Bridge doesn't get much attention.

[ycardozo]

robert, thank you so much. when i have a moment (on deadline now) will try to figure all this out. i live in fear of another update that screws me up. i knew (at the time) where to put the file but no matter how many times i replace it, it didn't 'take.' like i said, i eventually  had to get someone else to do it for me.

[Guest]

Since ACR will only work with one ACR file in the specified folder you also can put a tilde with 72 in front of the old one so it is not recognized, then download the new one.  The 72 would be the version as in the file they are only labled "camera raw" so one can not see what version it is.

I  contacted a Bridge Engineer to look into two Bridge issues that need some recoding to fix, they responded back they would, but have seen no further progress in last 2 months.  Hopefully ACR 7.4 will show it has been fixed.