• Global community
    • Language:
      • Deutsch
      • English
      • Español
      • Français
      • Português
  • 日本語コミュニティ
    Dedicated community for Japanese speakers
  • 한국 커뮤니티
    Dedicated community for Korean speakers
Exit
2

Bridge 2018 re-caching all thumbnails - AGAIN!

Participant ,
Oct 22, 2017 Oct 22, 2017

Copy link to clipboard

Copied

As long as I can remember (which is a long time), Bridge has forced re-caching of its thumbnails every time a new version of Camera Raw is installed. I just installed 2018 and here we go again.

I've participated in numerous forum discussions over the years, provided ample evidence of the issue, yet Adobe still can't seem to get it. And it seems like a simple problem with an easy solution.

I've got over 30,000 images in folders, 100 to 500 images per folder. I "Export Cache to Folders" and keep the main cache size small. So, when I navigate to a folder, Bridge copies the folder cache to the main cache and displays the thumbs. That's very quick. Unless Bridge decides the cache thumbs are "out-of-date", in which case it scans all the main images to rebuild thumbs. That's very slow and gives sluggish performance - from 2 to 5 minutes depending on folder size and image type (raw files take much longer). Many hours over many weeks as I browse my 30,000 images.

Why does Bridge decide the thumbs are out-of-date? Why is it using Camera Raw to make that decision? I can only guess, and my guess is that there is a difference in precision of the dates. Bridge compares the date of the main file to the date of the thumbnail, and they are off by some small fraction of a second. If that's the case, then the solution is obvious. Round the two dates to the whole second. 

Views

5.5K

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines

correct answers 1 Correct answer

Participant , Nov 05, 2021 Nov 05, 2021

I had a few of those too("dancing XMPs". When I chased it down I discovered they were orphaned XMP files. No raw file to match the XMP. Once they were deleted the dancing stopped.

Votes

Translate

Translate
Adobe Employee ,
Oct 22, 2017 Oct 22, 2017

Copy link to clipboard

Copied

Hi Ryan,

Is the option "Prefer thumbnail generation over preview generation" checked or unchecked.

Regards,

Gautam

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Participant ,
Oct 23, 2017 Oct 23, 2017

Copy link to clipboard

Copied

The "prefer thumbnail generation" is checked on my system. Must be the default, as I've not paid any attention to that one. Strangely, neither Google nor Adobe Help shows any info on that option. What does it do?

Regardless, I doubt it has any impact on the problem of regeneration. I've kept copies of Camer Raw.8bi back to version 8. When a new version of Camera Raw or Bridge starts re-caching everything, I simply replace the new version of Camera Raw with the most recent old version to test. Re-caching stops. Put the new version back, and re-caching starts again.

Let Bridge cache a few folders with a new version of Camera Raw. Put an older version in place, re-visit those same folders and Bridge re-caches them again. Put the new version back, re-visit folders again, and re-caching happens.

Return to the original questions. Why is Bridge using Camera Raw to make the caching decision? Seems that decision would be based on file name, date modified, and maybe file size. All that info is available from the OS.

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Adobe Employee ,
Oct 24, 2017 Oct 24, 2017

Copy link to clipboard

Copied

Hi ,

You can try few of these options

1. In preferences panel under cache->increase the cache size to max.

2. Check purge cache older than n days . Increase the n value.

3. Automatically Export Cache to a folder when possible.

Please let us know that cache or thumbnails are regenerating in central cache or in Exported cache folder. Also please mentioned how you are updating  Camera Raw.

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Participant ,
Oct 24, 2017 Oct 24, 2017

Copy link to clipboard

Copied

Avinash,

Thank you for your attention. Please be aware that this issue has existed for a long time. Below are links to other Adobe forum threads dating back to 2012. I realize that the issue is difficult for Adobe to address, since it appears to be system dependent, and thus hard to duplicate.

To answer your questions and suggestions:

I have run the cache size from the minimum 10,000 to the maximum 500,000 and various points in between. Cache size does not make a difference. And the number of images cached also appears to make no difference. I have the purge cache option disabled. I never purge. If I want an empty cache I delete the entire cache folders with Explorer. I have always Exported Cache to folders.

Sometimes thumbs are regenerated in the central cache, sometimes not. Likewise, the exported cache in folders (.BridgeCache and .BridgeCacheT) are usually regenerated by not always. That remains somewhat of a mystery.

I point a new Bridge /ACR at a root folder with many sub-folders. All of which were cached by a previous version. I then select "Show items from sub-folders". That will regenerate thousands of images and take a long time. When it's finished, I browse the folders with Explorer. Some of the .BridgeCache files are updated (new date) some are not. However, when I then point Bridge directly at one of the sub-folders with old .BridgeCache files, it then exports new versions.

Long ago I started copying the Camera Raw.8bi files to a private folder whenever a new version came out. I have copies going back to 7.1. To switch versions, I simply close Bridge, copy whatever version I want to test from my private folder to the Adobe folder, and re-launch Bridge. Currently, I can switch back and forth between versions 9.7 and 10.0 and witness some re-caching each time.

In these old threads others share various theories on what variables cause the issue. I think I'm the only one proposing that the version of Camera Raw is the key variable, but I don't think anyone else has tested that theory.

https://forums.adobe.com/message/8051540#8051540

https://forums.adobe.com/thread/1434395

https://forums.adobe.com/thread/1406698

https://forums.adobe.com/thread/1115020?start=0&tstart=0

https://forums.adobe.com/message/6028362#6028362

https://forums.adobe.com/thread/1024624?start=0&tstart=0

https://forums.adobe.com/thread/1074633

https://forums.adobe.com/message/4583632#4583632

https://forums.adobe.com/thread/1007560Deasr

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Community Beginner ,
Jan 04, 2018 Jan 04, 2018

Copy link to clipboard

Copied

can you explain what that setting does (Prefer thumbnail generation over preview generation). I too have never seen it and a bit confused. 

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Community Expert ,
Sep 27, 2018 Sep 27, 2018

Copy link to clipboard

Copied

Yes, me too.

I want to know what this means:

"Prefer thumbnail generation over preview generation"

Is the thumbnail image embedded in the image while the preview generation in the external cache?

Mike Witherell

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Adobe Employee ,
Oct 15, 2018 Oct 15, 2018

Copy link to clipboard

Copied

Hi All,

We have released a new version of Adobe Bridge (CC 2019) on 15 October 2018. The new version build number is 9.0.0.204. This version is available to install via Adobe Creative Cloud application.

Please check the following link to know about all new features in Adobe Bridge CC 2019 - https://helpx.adobe.com/bridge/using/whats-new.html

You may need to update the Creative Cloud application and restart your computer to see the updated installer.

Thanks,

Deepak Gupta

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Participant ,
Oct 25, 2018 Oct 25, 2018

Copy link to clipboard

Copied

I installed Photoshop and Bridge 2019 on a Surface Pro4 running Windows 10 version 1803 last week. This is a new and different computer than the ones I have used in the past to test and document Bridge re-caching.

Again. Bridge 2019 re-caches all images for no apparent reason. The images have not changed. The thumbnail jpegs do not change after re-caching. Same as all previous versions dating back several years now.

A mystery within the mystery is that no one from Adobe has ever confirmed or denied this problem. Even a denial would be helpful. It only takes a few minutes to test, assuming you have access to old versions of Camera Raw.8bi and can swap them in and out.

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Adobe Employee ,
Oct 25, 2018 Oct 25, 2018

Copy link to clipboard

Copied

Hi ,

Bridge requires cache to be generated when the version of Bridge is changed.

Once cache for all files is generated in Bridge CC 2019, the cache is not regenerated unless files are added or updated.

Please let me know the workflow in which  Bridge is regenerating cache .

Regards,

Abhishek Seth

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Adobe Employee ,
Oct 26, 2018 Oct 26, 2018

Copy link to clipboard

Copied

Hi redcrown on guard​,

Please check the Bridge cache location in Preferences dialog. In general, each version of Bridge has a separate cache.

However, you can make Bridge point to common cache folder location to avoid re-caching.

Bridge.png

From Bridge CC 2019 onwards, Bridge will be pointing to a version independent cache location.

Thanks,

Deepak Gupta

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Participant ,
Oct 28, 2018 Oct 28, 2018

Copy link to clipboard

Copied

AbhishekSeth, Deepak Gupta, Avinash Kumar Singh,

Dear Gentlemen,

I appreciate your participation in the forum, but I have to say that you just don't get it yet.

For a long time now, there has been no change in the structure of the Bridge cache. The folders used to store the cache are the same, the thumb and preview images stored in those folders are the same, the "Store" database (SQlite) is the same.

AbhishekSeth said "Bridge requires cache to be generated when the version of Bridge is changed." Why is that? What triggers building the cache? Since there is no apparent change in the base logic and structure of caching, the only reason should be that the thumbs no longer match the image. But they do!

Installing Bridge 2019 lets Bridge 2018 survive. So you can run both, just not at the same time. However, both versions point at the same Camera Raw.8bi file. So, after installing 2019 your 2018 version has a new Camer Raw.

So try this "work flow":

1. Get yourself some old copies of Camera Raw.8bi. If you work at Adobe that should be easy. If not, just ask. I've got them going back to version 8.6.

2. Point both Bridge 2018 and 2019 at the came cache location.

3. Make sure the new Camera Raw v11.0 in the target location (88,752 KB).

Program Files/Common Files/Adobe/Plug-Ins/CC/File Formats

4. Launch Bridge 2019, point it at a "virgin" folder of images that has never been cached, watch it cache.

5. Stop Bridge 2019, re-launch, verify it does not re-cache.

6. Launch Bridge 2018. Point it at the same folder. See that it does not cache. Sounds good so far.

7. Now the fun part! Close Bridge. Delete the current Camera Raw.8bi file. Copy an old version of Camera Raw into the master location and rename it Camear Raw.8bi. Version 10.0 is 70,785 KB.

8. Launch Bridge 2019. Watch it re-cache images!!! Why? The only thing that changed was the version of Camera Raw.

So here I am, sitting on a 400gb library of 40,000 images in 400 folders. My Bridge cache is 23gb. I install a new version of CC and get a new version of Camera Raw. It makes my existing cache obsolete. Everything will be re-cached. Even though I have "Exported cache to Folders" and all my image folders have valid BridgeCache and BridgeCacheT files. Re-caching will take many hours.

I realize that I am one of the few surviving Bridge users who has not migrated to Lightroom. We are a shrinking group, and I fully expect Bridge to be dropped by Adobe in the future. But Guys, as an old programmer I firmly believe this "bug" has a simple cause and could be easily fixed if it just received attention from the appropriate techies at Adobe.

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Adobe Employee ,
Oct 29, 2018 Oct 29, 2018

Copy link to clipboard

Copied

Hi redcrown on guard,

Changing the CameraRaw plug-in does mean that there may be additional capability available in updated plug-in which is relevant for regeneration of thumbnails, and this is the way plug-in support has been designed.

Your suggestion that changing the plug-in should not trigger to re-generate cache of thumbnails, will break the plug-in update happening independently outside of Bridge.

However, if you keep the plug-in version same, and keep the cache location same as in previous version of Bridge (as I suggested in my previous message), then Bridge will not re-cache the thumbnails again.

Thanks,

Deepak Gupta

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Participant ,
Oct 30, 2018 Oct 30, 2018

Copy link to clipboard

Copied

Let's try these simple questions:

1. Why does Bridge need to re-cache the thumbnails for an image?

I'd suggest the answer is because the thumbnail no longer matches the image. The image must have been edited with changes.

2. So, how does Bridge decide that the thumbnail no longer matches the image?

There are only a few variables to use for this decision. They "might" be the image size, the date and time, the bit depth, the color mode, or the color profile. But you would not need anything more than the date/time (last modified). Any changes to other variables will cause the date time to change.

So you have the image file name, including the full path, plus the date/time stamp. That's the only key you need. You get the file name from the operating system, look it up in the Bridge Cache "Store" database, and compare the date/time from the Store to the date/time from the OS. If they are the same, move on. If not, re-cache the thumbnail and update the Store entry.

But there is a problem somewhere in that logic. Either some other variables are being used, or the "If date-time-of-STORE = date-time-of-OS" test is giving false negatives.

So, for our Adobe friends here in the forum... How would you answer questions 1 & 2?

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Participant ,
Nov 06, 2018 Nov 06, 2018

Copy link to clipboard

Copied

I'm back with an update. Since none of the Adobe team answered the 2 questions above, I have to assume they don't know.

But on closer inspection and testing I find that the caching in 2019 is different in 2 ways. That is probably enough to cause the re-caching.

First way: The jpegs cached in the "256" folder are different. They are larger in bytes, and strangely (very strangely) they are highly pixelated. This indicates that 2019 is using a different conversion or compression method. Why is a good question. Larger file sizes, lower quality!

Note that the "256" cache jpegs are probably not used for anything. They only get used if you size the thumbnail display in Bridge to that small size. I suspect most people make them bigger, in which case the "1024" cache jpegs are used to display thumbs in Bridge.

The jpegs in the "1024" folder are identical between 2019 and all prior versions. I use "Generate monitor sized previews" so the jpegs in the "1024" folder are not 1024, but 1920 to match my current monitor. Why they are unchanged while the 256 jpegs are changed is a mystery.

Second Way: Exporting cache to folders, which is an option NOT enabled by default.  In 2018 and all prior editions, exporting cache to folders created two files called ".bridgecache" and "bridgecacheT". Yes, the filenames begin with a dot and have no extension in violation of Microsoft's recommendations.

In 2019 those files are not created and any old versions are ignored. Instead, 2019 creates a sub-folder called ".BridgeSharedCache" under the image folder. This folder contain more sub-folders in the same structure as the main cache (256, 1024, data, full). So, 2019 replaced two files with many, many folders containing many, many jpegs. And the old ".BridgeCache(T)" files are left untouched and unused. In many cases, this means several gigabytes of space is left behind.

In 2018 and before, exporting cache to folders was a good thing. When Bridge navigated to an image folder that was not included in the main cache, it would copy data from the folder cache to the main cache. That was considerably faster than re-caching every image. It took a lot of extra disk space, but protected you when the main cache overflowed or became corrupted.

In 2019, the folder cache appears to NOT be used! If I delete the main cache, launch Bridge and navigate to a folder that includes a previously exported cache, the time to "generate thumbnails and previews" is the same as if the exported cache did not exist. No time is saved, as was the case in 2018. This can't be right. Why export cache if it's never used?

Discovering these aspects of 2019 was a challenge, because 2019 creates the exported cache files as "Hidden". You can't see them unless you config your Windows Explorer to show hidden files (not the default).

We will have to wait until the next version release to see if the "new" caching of 2019 saves us from re-caching. In the meantime, some advice to users: Don't bother to export cache to folders. Delete all your old ".BridgeCache(T)" files. They serve no purpose after 2019. In my case that was 30+ gigabytes.

Also, note that the "Generate Monitor Sized Previews" option does not survive the retention of preferences when 2019 is installed. It gets reset to the default "no", so all the "1024" jpges are actually 1024. When you display a full screen preview in Bridge (spacebar) you get a fuzzy image because it upscales the 1024 jpeg to whatever your screen size is. This cost me a few hours because that caching option does not appear under cache management where is belongs, and I forgot about it. It appears under "Advanced."

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Participant ,
May 17, 2019 May 17, 2019

Copy link to clipboard

Copied

Well, it's bad news folks. It's May, 2019, and Adobe released ACR 11.3. Guess what? Re-caching of all thumbnails again!

Woe is us.

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Explorer ,
Jun 06, 2019 Jun 06, 2019

Copy link to clipboard

Copied

If your image files are tiffs, make sure the file extension is .tif and not .tiff. The only files that get recached (for me at least) have a .tiff extension.

Or you can go to Edit > Camera Raw Preferences > File Handling and tick "Disable tiff support" and "Disable jpeg support." There will be one final (and much faster) round of recaching, and then Bridge should leave your thumbnails alone as far as Camera Raw is concerned. When tiff / jpg support is Enabled, the default Camera Raw ("Auto") settings are applied to every file in a folder to generate prettier-than-average thumbnails. When tiff support is disabled, you get the unadjusted thumbnails without all the recaching.

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Community Beginner ,
Jun 19, 2019 Jun 19, 2019

Copy link to clipboard

Copied

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Participant ,
Oct 29, 2018 Oct 29, 2018

Copy link to clipboard

Copied

This has always seemed to be the case since I've been using Bridge (a long time.) In the bottom status bar it always says (Generating thumbnails...) regardless of what I am viewing. It can be a folder with a single image in it. I would not expect this to change.

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Adobe Employee ,
Jun 14, 2019 Jun 14, 2019

Copy link to clipboard

Copied

Hi redcrown on guard,

Thank you for your feedback regarding re-caching of thumbnails on ACR update. We will continue to incorporate the feedback to enhance the experience.

Thanks,

Varun Varshney

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Participant ,
Nov 01, 2021 Nov 01, 2021

Copy link to clipboard

Copied

Well folks. It's November 2021 and Adobe released major updates. We get a new Photoshop, Bridge, and Camera Raw. All the hype and attention is on the new masking features in Camera Raw (and Lightroom).

But guess what lurks in the background? Re-caching! Again! Bridge 12.0.0.234 plus Camera Raw 14.0.0.950 are incompatible with previous versions of the Bridge Cache. The new system will re-cache everything! And it does it in a strange way I can't figure out. It leaves old cache jpegs behind and those old jpegs can't be cleared out with "Compress Cache" or even "Purge Cache". (This on Windows 10, don't know about MAC).

So, buyer beware - nuke your cache and let Bridge/ACR start from scratch. Else you will carry around gigabytes of old, unused files. No easy way to find and delete them later.

That's bad news, of course, but there is more. The new system is re-caching itself again. And it does it in the same old strange way that defies logic. Cache a folder of images, navigate to a different folder and then come back to the previously cached folder. Watch "Generating Previews" or "Indexing" flash by on the bottom status bar.

With Windows Explorer, find the actual folder of jpegs in the Bridge Cache itself. Look at the creation dates vs. date modified. See that SOME of the files have a new date modified, matching the time you saw the re-caching. Not all the files, just some. And as in the past, I can find no logic here. Raw, DNG, TIF, Jpeg extensions, different cameras, different dates... no common attributes.

According to my gene pool, I'll be dead in 5 years. That's when I'll stop complaining about this.

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Participant ,
Nov 03, 2021 Nov 03, 2021

Copy link to clipboard

Copied

Mini Update... Noticed something interesting when studying the files that cause re-caching. While there are samples of all kinds, most dominant are raw files with adjustments. So, DNG or CR3+XMP.

And the fun part - if I make a new adjustment to those re-caching raw files, re-caching stops! Then, more fun, if I remove that new adjustment and return the file to the original state, re-caching still stops.

Example: I have a folder with 134 raw DNG files and Bridge was re-caching 30 of them. I opened those 30 in ACR and added 1 point of Saturation. No more caching. I opened them again and reset the Saturation to 0. Still no caching. Continued this experiment making different adjustments. It makes no difference what kind of adjustment I make and then remove. Re-caching ceases after the new Bridge/ACR touches the file.

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Explorer ,
Nov 05, 2021 Nov 05, 2021

Copy link to clipboard

Copied

Every folder that I now open in Bridge 12 since the Nov 2021 update is full of dancing xmp files.  I've been using PS for nearly 20 years and every update seems that there are more problems and few if any real improvements.

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Participant ,
Nov 05, 2021 Nov 05, 2021

Copy link to clipboard

Copied

LATEST

I had a few of those too("dancing XMPs". When I chased it down I discovered they were orphaned XMP files. No raw file to match the XMP. Once they were deleted the dancing stopped.

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines