Skip navigation
Currently Being Moderated

Bridge 4.1.0.54: Error writing Metadata to some [....].jpg

Aug 8, 2011 1:55 AM

I am sorting my files (.JPG) with bridge. Some files just can't get rated (bridge fails without giving me an error), and if I try to set other metadata (like keywords), bridge tells me "There was an error writing metadata to ".....JPG".

I have full access to the folder, it is an internal disk, the files are not locked. It affects about 5% of all files - this is the second shooting (&folder) where I have this problem. I don't see any differences between the files I can change and the ones where I can't.

I can rename the file with bridge, but that does change nothing. I tried purging the cache, it changed nothing.
I just found out: I can change the tags with Windows Explorer, Bridge does show them, and afterwards I can change them with bridge too. Someone got an Idea how I can avoid this step?

 

[Win7Pro x64, i7]

 
Replies 1 2 Previous Next
  • Currently Being Moderated
    Aug 8, 2011 7:44 AM   in reply to NukeyAut

    I have seen this problem with jpeg 2000 photos where tags can not be added.

     

    Have you tried to open in PS and then "save as"  with a different name?  Might be some weird file error.

     
    |
    Mark as:
  • Currently Being Moderated
    Aug 31, 2011 11:14 AM   in reply to Curt Y

    I have the same issue (sort of...) My photos are located on a server running Server2008. Usually I can rate the photos but then go to add other metadata (e.g. Keyword or Tag) and get the error message. However, if I wait awhile (not just a few seconds, but can be as long as a minute or so), then I can write the metadata. To me, this likely shows that there is some problem and/or incompatiability (with Windows 7/Server2008) in the Bridge file write caching (i.e. the file is still locked from a previous write attempt when it tries to add the new metadata).

    I have a wired 1G LAN and fast computers (including the server) and lots of memory, so I'm sure it is not network/memory lag.

    I haven't played with any Sever2008 and/or Windows 7 settings; or for that matter done any work on the write cahing methods employed for Server2008. (I do have write caching enabled on my local harddrives - but I'm assuming any write caching for the server is independent.)

    Any thoughts or explanations regarding Bridge writes it's metadata would be appreciated (e.g. does it locally cache changes and do a bulk update?)

     
    |
    Mark as:
  • Currently Being Moderated
    Aug 31, 2011 7:32 PM   in reply to Camakazi

    It is a known issue that write metadata error to JPG and Tiff on a network shared Win7 or Win2008 server OS.

    Bridge team is working on it.

     

    Thank you for report it.

     

    Melissa

    Bridge QE

     
    |
    Mark as:
  • Currently Being Moderated
    Sep 2, 2011 12:34 AM   in reply to Jingshu Li

    Jingshu Li wrote:

     

    It is a known issue that write metadata error to JPG and Tiff on a network shared Win7 or Win2008 server OS.

    Bridge team is working on it.

     

    Thank you for report it.

     

    Melissa

    Bridge QE

    What about "Error writing metadata..." from the last few versions of CS on various versions of Windows (XP and 7 at least)? I have experienced this for years, especially when keywording using Collections of images from different folders.

     

    It seems to me to be an issue with Bridge and file locking, with Bridge being unable to write to some files even though they are not opened.

     

    My workaround has always involved one of the following:

    1. wait several minutes until Bridge has stopped enumerating files

    2. open the offending file(s) with Bridge, change some insignificant setting and save them again

    3. restart Bridge

     
    |
    Mark as:
  • Currently Being Moderated
    Sep 2, 2011 12:55 AM   in reply to NukeyAut

    Dear NukeyAut,

     

    I notice you mentioned some of your jpg files have the write metedata error issue. So some other jpg files in your folder don't have the issue, right?

    If so, I have several questions:

    1. Do you create the jpg files with the issue and without the issue in same way? e.g, do you create the 2 kinds of jpg files by same camera model?

    2. What will happen if you move the jpg files with the issue to your desktop? How about to switch to another user account and then apply metadata to the jpg file? How about use another Windows 7 machine?

    3. Could you please help to sent a sample jpg file with the issue to me?

     

    Thanks,

    Melissa ( jingshu@adobe.com )

    Bridge QE

     

     

    NukeyAut wrote:

     

    Dear Melissa,

     

    this is a single-user installation (win7 pro x64) without any network

    involved.

     

    Best Regards,

    Simon Jiménez

     

     

    Am 01.09.2011 04:33, schrieb Jingshu Li:

    It is a known issue that write metadata error to JPG and Tiff on a network shared Win7 or Win2008 server OS.

    Bridge team is working on it.

     

    Thank you for report it.

     

    Melissa

    Bridge QE

    >

     
    |
    Mark as:
  • Currently Being Moderated
    Sep 2, 2011 1:01 AM   in reply to Yammer

    Dear Yammer P,

     

    I would like to clarify the issues you've met.

    Do you mean usually you'll see the 'Error writing metadata...' error when you apply (especially) keywords to images in a collection?

    If so, do you usually use camara raw files in the collection?

    Actually there's another known issue that when apply metadata to camera raw files in collection will cause the error in some certain steps. I'm wondering to make sure if your issue is the know issue or not.

     

    Thanks,

    Melissa

    Bridge QE

     

    Yammer P wrote:

     

    Jingshu Li wrote:

     

    It is a known issue that write metadata error to JPG and Tiff on a network shared Win7 or Win2008 server OS.

    Bridge team is working on it.

     

    Thank you for report it.

     

    Melissa

    Bridge QE

    What about "Error writing metadata..." from the last few versions of CS on various versions of Windows (XP and 7 at least)? I have experienced this for years, especially when keywording using Collections of images from different folders.

     

    It seems to me to be an issue with Bridge and file locking, with Bridge being unable to write to some files even though they are not opened.

     

    My workaround has always involved one of the following:

    1. wait several minutes until Bridge has stopped enumerating files

    2. open the offending file(s) with Bridge, change some insignificant setting and save them again

    3. restart Bridge

     
    |
    Mark as:
  • Currently Being Moderated
    Sep 2, 2011 1:38 AM   in reply to Jingshu Li

    Jingshu Li wrote:

     

    Do you mean usually you'll see the 'Error writing metadata...' error when you apply (especially) keywords to images in a collection?

    If so, do you usually use camara raw files in the collection?

    Actually there's another known issue that when apply metadata to camera raw files in collection will cause the error in some certain steps. I'm wondering to make sure if your issue is the know issue or not.

    I'm dealing with Smart Collections or searches of tens or hundreds or thousands of raw images from a three-tiered folder structure of about 20,000 images. The raw images are proprietary Nikon files with sidecar files, processed only in Camera Raw. I would make selections of tens of images and apply (or remove) keywords, but often the Error Writing Metadata message would pop up for anything from one to most of the selected files.

     

    Each error requires clicking on an OK button, which can take an eternity, and leaves many files unmodified. Trying the files again usually (but not always) results in the same error message. The longer you leave it, the better your chances.

     

    Sometimes it would be fine. It seemed to get worse the longer I ran Bridge, and I would usually restart Bridge when things got unbearable.

     
    |
    Mark as:
  • Currently Being Moderated
    Sep 9, 2011 2:19 AM   in reply to NukeyAut

    Dear NukeyAut,

     

    Thank you for the sample test file. I reproduced the issue in my testing machine and now the developer is investigating it.

    Here I have another workaround: if you usually won't use ACR (Adobe Camera Raw) to edit the JPG files, you can set 'Disable JPEG support' from Edit -> Camera Raw Preferences -> JPEG and TIFF Handling -> JPEG. And then you can write metadata to the jpg file in Bridge, no need to change the tags with Windows Explorer.

    Thank you again for reporting the issue.

     

    Melissa

    Bridge QE

     
    |
    Mark as:
  • Currently Being Moderated
    Sep 9, 2011 2:28 AM   in reply to Jingshu Li

    Dear Yammer P,

     

    I tested your issue but haven't reproduced yet. Could you please provide more info?

     

    1. You mentioned usually you will select tens of images (in the smart collection or search result) and apply metadata, and then you get the error. I'm wondering can you apply metadata successfully if you only select one image and then apply metadata?

    2. Before you apply metadata, do you wait for the images thumbnails genaration complete?

    3. Can you apply metadata successfully if you selete the images at their real location (not in the smart collection or search result?)

    4. Your OS info, mac or win, and version?

     

    Thanks,

    Melissa

    Bridge QE

     
    |
    Mark as:
  • Currently Being Moderated
    Sep 9, 2011 6:04 AM   in reply to Jingshu Li

    Jingshu Li wrote:

     

    I tested your issue but haven't reproduced yet. Could you please provide more info?

     

    1. You mentioned usually you will select tens of images (in the smart collection or search result) and apply metadata, and then you get the error. I'm wondering can you apply metadata successfully if you only select one image and then apply metadata?

    2. Before you apply metadata, do you wait for the images thumbnails genaration complete?

    3. Can you apply metadata successfully if you selete the images at their real location (not in the smart collection or search result?)

    4. Your OS info, mac or win, and version?

     

    I just set up a quick test, and it failed immediately. I haven't even been using Bridge today...

     

    The computer runs CS5 on Windows 7 Professional 64-bit. I used to run CS3/CS4 on a different computer loaded with Windows XP Professional. I'm always up-to-date with OS/driver/application updates. Both systems exhibited the same problem.

    The raw image 3-tier folder hierarcy is on a separate internal drive: P:\Camera\2011\08-15 Location\, P:\Camera\2011\08-16 Location\, etc.

    The Bridge cache is on a separate internal drive: T:\BridgeCS5\, Camera Raw's cache is in T:\CameraRaw\.

    The images are mostly Nikon NEF (D300), and ACR saves settings to 'sidecar' files. Most of the images have settings, and many have crops.

     

    I created a new Collection, and dragged the contents of 7 image folders into it - a total of 407 images. None of these files have had keywords applied, but most had been worked in Camera Raw already. After waiting for thumbnail/preview generation to finish, I selected the collection, created a new sub-keyword, selected all images in the collection, and ticked the new keyword (automatically ticking the parent keyword). Within a few seconds, I started getting the "Error writing metadata..." warnings, and had to OK 15 images.

     

    The failed images were spread across 3 of the 7 selected directories. Trying the same thing 30 minutes later resulted in the same errors. Trying each failed image individually gave the same error (either as part of the collection, or from it's own folder).

     

    I opened one of the problem images in Camera Raw, and adjusted Blacks, clicking Done to save the settings. I then tried to apply the keywords again. This time it worked.

     

    To answer your questions directly:

    1. I have never experienced this problem keywording files individually (apart from after the errors, as mentioned above), but then I wouldn't usually be selecting lots of images to keyword individual images.

    2. Yes, I always wait for the spinning circles to disappear, sometimes even longer!

    3. I just tried applying keywords to a single folder of 102 images, and 2 failed to update. So the answer is No, it fails at real locations too.

    4. Windows 7 Professional 64-bit, running on Intel Core2 Duo and 4GB RAM. Same thing happened before on a Windows XP Professional PC, running on an Intel Pentium 4 and 2GB RAM and a single hard drive.

     

    I hope that helps.

     
    |
    Mark as:
  • Currently Being Moderated
    Sep 9, 2011 6:08 AM   in reply to Yammer

    I should add that, in the past, I have become so frustrated by this and regular unnecessary thumbnail/preview updates, I have resorted to Ctrl-start and reset Bridge to defaults, but the problems have always returned.

     
    |
    Mark as:
  • Currently Being Moderated
    Oct 14, 2011 9:22 PM   in reply to NukeyAut

    I'm having the exact same problem.  And the file content, camera, everything is identical.  The keyword tagging problem only occurs on some, not all of my photos, so I can't understand why this is happening.  I should also mention that I typically don't use Camera Raw to edit photos (although I do occasionally).  And I tried the suggested workaround (to disable the jpeg support), and it didn't help resolve the problem.  Will Adobe correct this problem on their next update?

     

    Thanks,
    Suzanne

     
    |
    Mark as:
  • Currently Being Moderated
    Nov 16, 2011 12:34 AM   in reply to Jingshu Li

    Any progress?

     
    |
    Mark as:
  • Currently Being Moderated
    Nov 16, 2011 2:22 AM   in reply to Yammer

    Dear yammer,

     

    I appologize that not reply you for so long time.

    From the description of the issue, it seems parts of your Nikon D300 NEF files cause this issue. I tested all my Nikon D300 NEF files but still cannot reproduce it. Could you please provide me a sample file? Please email me (jingshu@adobe.com). If the file is too large and cannot be sent by email, please also tell me through email, and I'll provide a FTP server to you to upload the sample file.

     

    Beside, I still have 2 questions:

    1. Where are your Nikon D300 NEF files located? On a local disk or you need to access them through network?

    2. If you copy the file onto your Desktop and then apply keyword, will the metadata get applied successfully?

     

    Thanks,

    Melissa

    Bridge QE

     
    |
    Mark as:
  • Currently Being Moderated
    Nov 17, 2011 9:58 AM   in reply to Jingshu Li

    I have emailed a NEF and sidecar to you. I think the sidecar is the root of the problem. It will only accept a keyword if it is first updated by Camera Raw or the settings cleared. There must be a problem with the content of the XMP which causes Bridge to give up. The XMP provided is unmodified.

     

    In answer to your questions:

     

    1. The files are on an internal RAID array, which is an NTFS volume, drive P:. Previously, they were on a single drive, with the same problem.

    2. Copying the problem files to a new location, either the desktop or another volume produces the same results, with the same files failing to accept keywords.

     

    There is NOTHING obviously different about the files which fail. They seem to be randomly chosen. Some have more complex settings than others. Some have crops. In one shoot, taken over several minutes, most will work, but some will fail.

     

    Hopefully, the image I provided will fail for you, and you might be able to analyse the XMP for causes.

     
    |
    Mark as:
  • Currently Being Moderated
    Nov 18, 2011 12:49 AM   in reply to Yammer

    I've done some more experimentation this morning, and I think I'm getting closer to the cause of the problem.

     

    I have a batch of 460 photos in several folders which I have duplicated in two other locations.

    On keywording, the metadata occurs in the same files in each location, so the location is not the problem, it's the files.

    In every case, modifying one parameter in Camera Raw will fix the metadata error. The only thing that changes is the file's sidecar.

     

    I have done a text diff on several XMP files, before and after Camera Raw use, and there are several things besides the intentional change which happen...

     

    1. The metadata date and instance ID are updated.

    2. The history list is appended to.

    3. The default lens profile details are added (6 parameters)

    4. The crop parameters are updated

     

    I don't think the lens profile changes are significant because files which produced no metadata error had no additional lens profile details either.

     

    It is the last one of these which I think is significant. In all files I tried (failed or not), the crop parameters had changed after an update of a single trivial basic setting (e.g. Recovery or Clarity), even though the crop wasn't touched! I noticed that all the failed photos had a crop - apart from one. I checked the uncropped photo's XMP file before and after a setting change, and, interestingly, the before version had crop settings and the after version had none! I had previously thought that it might be only the cropped files which gave the problem, but was proved wrong - it now seems that even uncropped files can have crop data.

     

    So, my conclusion is that Bridge throws up the metadata error because it cannot parse the XMP data. Certainly in my case, a problem in the crop metadata seems to be the cause, and the best way to fix this is by allowing Camera Raw to parse and re-save the data.

     

    The questions are: why/how is the crop data wrong, and how can it be fixed without opening each individual file?

    Maybe I need to open 20,000 images in Bridge, change an unused parameter then change it back again? Who's to say the probem won't reoccur later?

     
    |
    Mark as:
  • Currently Being Moderated
    Nov 18, 2011 3:10 AM   in reply to Yammer

    Dear Yammer P,

     

    I received your sample NEF file with the XMP file but unfortunately I still cannot reproduced the issue in my testing machine.

     

    I re-arrange all the info so far and need to check with you if I didn't mis-understand your problem and didn't missing something:

    1. All the files are generated by Nikon D300

    2. All the files (failed or not) have the sidercar XMP file.

    3. Part of files are failed to write metadata, and part of not.

    3. Once modified any parameter in ACR for the files (failed or not), the write metadata error will not occur any more.

    4. All the failed files have crop paramater in sidercar XMP file, most of the failed files crop data will be updated after modified any irrelevant setting in ACR. Only one of the failed file has crop data before edit in ACR, while the crop data was cleared after edit in ACR.

    5. Bridge version is 4.0.5.11 and ACR version is 6.6

     

     

    Please correct me if my understanding is wrong or missing something.

     

    Although I haven't reproduced the issue with your sample files, I want to try again with ACR crop feature next week. I may need more info from next week.

     

    Thanks for all the info so far.

    Melissa

    Bridge QE

     
    |
    Mark as:
  • Currently Being Moderated
    Nov 18, 2011 7:37 AM   in reply to Jingshu Li

    I am surprised the keywording worked. It doesn't seem to matter where I put these files.

    Just to check: you copied both the NEF and the XMP and tried to apply keywords without opening the image first?

     

    The only other factor which I have not taken into consideration is the Bridge database. Maybe duplicates are handled by the same database entry, in which case that image will only fail on my computer.

     

    1. Yes, all D300

    2. Yes, all have XMP sidecar.

    3. Usually 0–20% will not accept keywords. I have to click OK on each failed image.

    4. Yes, all have crop parameters in XMP - even one file which had no crop symbol. Crop parameters seem to get updated, regardless of the metadata problem.

    Maybe 25% of all my files are cropped, but most cropped files do not necessarily get the metadata error.

    5. Bridge is 4.0.5.11 and ACR is 6.6RC1, but I've seen this problem for a very long time, maybe even as long ago as CS3, definitely CS4.

     

    Thanks for persevering.

     
    |
    Mark as:
  • Currently Being Moderated
    Nov 23, 2011 12:47 AM   in reply to Yammer

    Dear Yammer P,

    Just to check: you copied both the NEF and the XMP and tried to apply keywords without opening the image first?

    Yes, I download both the NEF and the XMP on my Win 7 desktop, open Bridge and then apply keyword, without opening the image in ACR or PS first.

     

    I still cannot reproduce the issue after trying to set crop in ACR 6.6.

     

    Have you ever use other app to edit the image before crop it in ACR?

     

    And, could you please help to check if it can apply keywords when you download the image from the link you've emailed me?

     

    Thanks,

    Melissa

    Bridge QE

     
    |
    Mark as:
  • Currently Being Moderated
    Nov 25, 2011 7:41 AM   in reply to Jingshu Li

    I downloaded my own files and tried to apply keywords, and it worked fine this time.

    Clearly, this problem is quite complicated!

     

    Some of my NEF files have been updated in Nikon CaptureNX, but not since July 2008, when I stopped using it. The vast majority of the NEF files are untouched by human hand.

     

    I have tried various versions of Lightroom over the years, set to write to XMP for compatibility with Bridge/Camera Raw. The XMP files have been variously updated with every version of Adobe Camera Raw and Lightroom over a period of 3–4 years, starting with CS3.

     

    Last week, I was unable to generate a thumbnail image for one photo in Bridge. I purged the image's cache, deleted the XMP sidecar and replaced the photo from backup and it made no difference. I renamed a copy and placed it in the same folder, it generated a thumbnail straight away. It seems to me that Bridge is struggling with it's database. It's almost as if it had decided that particular file name was not going to work. It strikes me that this is similar behaviour to the metadata problem, where it decides that a particular file cannot be written to.

     

    I suspect that the error is down to my Bridge database, which is why you could not recreate the error with the file I uploaded. Presumably, having used Bridge a lot in the last week, something has changed in my database which also means that I cannot recreate the error with the same file.

     

    I decided to go mad, and did another Ctrl-start to clear Bridge's settings. I accepted the default cache location (it was previously on another internal drive). I tried to keyword a collection and it worked without error. I tried another collection straight away. It failed. There were so many errors, I had to End Task to save my finger. Clearly, a Bridge reset doesn't help much. Now I've got 20,000 previews and thumbnails to generate.

     

    I suggest creating several collections of 500+ images, select all in each collection, and try to keyword them with dummy keywords on multiple levels. For me, it will fail fairly quickly.

     
    |
    Mark as:
  • Currently Being Moderated
    Nov 25, 2011 8:19 AM   in reply to Yammer

    Yammer,

     

    Just a suggestion, when you find a file that does not work e-mail it to yourself and see if it still does not work before e-mailing to Jingshu.

     

    Not sure how the Camera Raw cache is handled on reset preference.  It may be purged also but have you purged that also?

     

    You refer to the Bridge database, I assume that is the central cache rather than storing your info in Camera Raw Database rather than XMP.

     

    Also, when you can not keyword in Bridge and you add the keyword in Win Exporer?

     
    |
    Mark as:
  • Currently Being Moderated
    Nov 25, 2011 9:01 AM   in reply to Curt Y

    Curt Y wrote:

     

    Just a suggestion, when you find a file that does not work e-mail it to yourself and see if it still does not work before e-mailing to Jingshu.

    Already tried it before I sent it! Great minds.

     

    The Bridge cache folder contains 4 folders: 256, 1024, full, & data. The first three are thumbnails, previews and 100% previews. The last one appears to be two databases. What these databases are for I don't know. Presumably, Bridge needs to track which images have already been cached (not that that seems to help, as many of my images are re-cached unnecessarily all the time); I would also guess that Bridge has a file lock system as well as databases for recently used folders etc.

     

    When I reset Bridge this week, it went from using one set of folders to another on a different drive. In effect, all previews and databases were discarded. I thought it was worth trying the default location, and deleting the old cache. The collections remained because they are stored elsewhere in the user profile.

     

    I always opt to save Camera Raw data in XMP.

     

    I never keyword in Windows Explorer. Only Bridge. However I don't do that much these days because the errors make it too painful in batches.

     

    What I'd like to know is why an image refused to generate a thumbnail, until I renamed it outside Bridge.

     
    |
    Mark as:
  • Currently Being Moderated
    Nov 25, 2011 9:25 AM   in reply to Yammer

    Yammer P wrote:

     

    What I'd like to know is why an image refused to generate a thumbnail, until I renamed it outside Bridge.

    Usually it is becasue there is some error in how the image file was constructed.  By saving it in another program whatever error was there, it was eliminated.  This is the same problem in a parallel thread http://forums.adobe.com/thread/925441?tstart=0 where OP can add metadata to files generated with his camera until he saves it in PS.

     

    In this case Jingsshu was able to reproduce the problem.  Hopefully the solution here will help in your solution.

     

    If you have a pic that does not work send me a copy in PM and I will see it if works for me.

     
    |
    Mark as:
  • Currently Being Moderated
    Nov 28, 2011 11:48 PM   in reply to Curt Y

    Curt Y wrote:

     

    In this case Jingsshu was able to reproduce the problem.  Hopefully the solution here will help in your solution.

    Let's hope so.

     

    I had another think about this problem, seeing as something is being done about it. I have another ongoing problem, which has also bothered me in the long term, related to thumbnail/preview generation. Despite ensuring that all my images are cached, Bridge regularly wants to cache some of them again, and again, and again. This can be a drain on resources, and slows the computer down. It occurred to me that, as well as the broken thumbnail, this problem could also be related.

     

    I have often purged the cache, or even removed it altogether, in the vain hope that problems will go away, but they always return. This week I started again, and had to cache over 20,000 photos, which I did using the Tools > Cache option this time.

     

    It occurred to me that the Bridge Cache, which is stored in a folder on the hard drive, not only contains generated JPEGs at thumbnail, preview and (optionally) 100% sizes, but it must also contain a keyword cache. Why else would Bridge include an "indexing" facility? It makes sense that, not only are the images cached, but some of their metadata is too, and it is this metadata cache which is used for searches and collections. I can't prove this, but as a someone who has written code for a living, it makes sense.

     

    If Bridge is having trouble accessing cached records in certain circumstances (searches/collections), then this may exhibit the symptoms of being unable to access the real data, as well as thinking that image previews need regenerating. It could also explain why some images' XMP appear to be unwriteable: maybe it's the "metadata cache" which is unwriteable, hence certain images only failing on my computer.

     
    |
    Mark as:
  • Currently Being Moderated
    Nov 30, 2011 10:03 PM   in reply to Yammer

    Dear Yammer P and Curt Y,

     

    Firstly thank you so much for the discussion and all the info so far. From all the previous discussion and testing, I feel and agree with you that this issue (include the metadata write error and the thumbnail error) is more likely a Bridge cache / database issue, however I haven't found a good way to reproduce it in my office. I've asked another Bridge QE who's focusing on cache / thumbnailing to try this issue together with me. We still need sometime and might need more infor from you.

    By the way, the issue in a parallel thread http://forums.adobe.com/thread/925441?tstart=0 (which I've already recreated) seems a different issue with this one. That issue is an XMP bug and it is unrelated to the Bridge working environment (I mean cache / database...) so it was reproduced more easily in my machine once I got the sample files.

     

    Thanks,

    Melissa

    Bridge QE

     
    |
    Mark as:
  • Currently Being Moderated
    Dec 2, 2011 4:10 AM   in reply to Jingshu Li

    Jingshu Li wrote:

     

    From all the previous discussion and testing, I feel and agree with you that this issue (include the metadata write error and the thumbnail error) is more likely a Bridge cache / database issue, however I haven't found a good way to reproduce it in my office. I've asked another Bridge QE who's focusing on cache / thumbnailing to try this issue together with me. We still need sometime and might need more infor from you.

    I don't think this problem will be easy to recreate reliably. I have been trying for months, and I still can't do it with any certainty. Also, it looks like it's unlikely that anyone will be able to supply you with faulty files, as it seems like Bridge is having trouble manipulating its database.

     

    I can recreate the fault quite quickly, but randomly. Sometimes it works, sometimes not. I can't work out what changes.

     

    For example. I have recently compiled several Collections of about 600–1000 images. I can't keyword either of the first two collections I have selected (Error writing metadata) either in full, or a sub-selection. So, I selected about 60 images and loaded them into Camera Raw, changing the Sharpness Amount slightly, and clicking Done to close. Once the circle stopped spinning, I tried to keyword again, and it worked perfectly.

     

    It seems to start with Collections or Finds—anything which groups images from different locations. Keywording files in these selections is hit and miss.

    If any files refuse to be keyworded, they stay in this state; that is, by leaving the selection, and visiting the file's folder, it still produces the error if you try to keyword it individually. But clearly, this is not a problem with the file, as it can be keyworded on another computer. There must be a database record for each image, and this record's contents must somehow get into a state where it cannot be keyworded, unless it is updated by Camera Raw.

     
    |
    Mark as:
  • Currently Being Moderated
    Dec 15, 2011 4:37 AM   in reply to Jingshu Li

    Dear Melissa,

     

    same issue here (Error writing metadata to a number of JPG files). It happens mostly while adding keywords in batch but can also happen also when labeling or rating just one file.

     

    If I open the file offending file in PS and resave it, then Bridge seems to be able to tag it, but it's hard to tell if that's because the file was resaved or because the new changes would be applied to only one file (rather than batch).

     

    I did a lot of software development and the route I would take would be to have Bridge display a specific error code when it cannot rate, label or tag a file, based on what the problem is.

     

    That would go a long way in helping zoom in on the problem.

     

    My platform: Mac OS X, both Snow Leopard and Lion.

     
    |
    Mark as:
  • Currently Being Moderated
    Dec 20, 2011 10:01 AM   in reply to NukeyAut

    I regurlarly have this issue with Bridge. I use NEF and TIF only and have 8000/10 000 photos per folder. I don't know what causes this. But I have noticed that it occurs often after I clean the system of temporary files or when I open bridge when there ia a heavy load on the processor.

     

    What I do is wait for Bridge to be done opening and then I press F5 to refresh. This has always done the trick for me. Maybe the criterias are not loaded properly. Who knows. Maybe Melissa can enlighten us on that.

     

    FYI: Windows 7 Home Premium 64 bit, U9400 1,4 GHz (Dual-core) intel processor, 4 GB RAM

     
    |
    Mark as:
  • Currently Being Moderated
    Dec 20, 2011 5:24 PM   in reply to Kul@

    Kul@, it seems like having 10,000 images per folder would put a heavy strain on the processor to built all the thumbnails especialy if HQ version.  The 4 gigs of ram probably probably does not help either.

     

    I don't know what the effect of the number of files per folder.  My thing is that there more images there are per folder the higher the chance of a cache error when building the thumbnails.  I know in CS3 errors were common and compounded by any switch from the folder before the thumnail building process was finished.

     

    With all that said I try to keep my files around 1,500 per folder and I use embedded thumbs.  Have never experienced a problem, but that could have nothing to do with folder size.

     

    Will be interesting to see if Adobe can ferret out the answer.

     
    |
    Mark as:
  • Currently Being Moderated
    Dec 21, 2011 1:55 AM   in reply to Curt Y

    It could well be related to number of images, but not necessaily in the same folder. It seems to affect me when working with large numbers in Collections or Finds. Otherwise, I tend to have quite low numbers of images in individual folders. Say 10-100.

     
    |
    Mark as:
  • Currently Being Moderated
    Dec 21, 2011 6:47 AM   in reply to Curt Y

    It is a choice to have a large number of images per folder. The intention is to ease keywording, metadata editing and batch processing. Bridge is meant for professionals and as such should be able to handle the load. With large projects and collections, it would be impractical to have them spread out over several folders to accomodate Bridge.

     

    As for my ultra portable, it is ideal for on the road and meets more than the minimum requirements to run CS5.

     

    For sure, it happens that the processor cannot handle the requests Bridge puts on it. The program should be designed to handle this. I think that Bridge drops the request to the processor when it does not get an answer quickly enough.

     

    The point of my post is that the workaround of this bug (In my opinion it is a bug) is to press F5 to refresh. This does the trick everytime. Some file must get corrupted because restarting Bridge and/or the computer doesn't restore my ability to edit image metadata only F5 does.

     

    I love Bridge by the way.

     
    |
    Mark as:
  • Currently Being Moderated
    Jan 4, 2012 4:55 AM   in reply to Jingshu Li

    I've logged this bug on the Photoshop.com website.

     

    http://feedback.photoshop.com/photoshop_family/topics/error_writing_me tadata_keywording_in_bridge

     

    Please feel free to visit the link and click the "+1" icon to add weight to this issue!

     
    |
    Mark as:
  • Currently Being Moderated
    Jan 23, 2012 10:31 AM   in reply to Jingshu Li

    Hello

     

    It's all gone quiet on this topic.

     

    Do you need any more information?

     

    Have you made any progress?

     
    |
    Mark as:
  • Currently Being Moderated
    Jan 23, 2012 6:11 PM   in reply to NukeyAut

    I thought I was on to something, and posed my results before finding this thread, so I'll simply link to it.

     

    http://forums.adobe.com/message/4159905

     

    Sure would like to see this resolved. I really like the idea of a more specific error code or something to ease the tracing of this super-annoying bug.

     

     

    ...Mike

     
    |
    Mark as:
  • Currently Being Moderated
    Jan 24, 2012 12:15 AM   in reply to theMikeD

    Not being a Mac person, I'm not sure I understand your posts. You have found a correlation between file attributes and the problem, but not the XMP data itself?

     

    What happens if you make a Camera Raw adjustment to a problem image, does this change the problem attribute?

     

    Our best guess on the Windows side is that Bridge is getting its internal database out of sync with reality, although it's difficult to tell for sure because there is no specific error reporting.

     

    I have noted myself that my collection of XMP sidecar files, which have been built up over 4 years, starting with ACR4, often look slightly different, as they have been untouched or updated with different versions of ACR for different adjustments. I don't know if inconsistencies in XMP structure, or a flaw in database management causes the metadata error to start, but in my case I strongly suspect that it is the database management. This because, I can almost guarantee the problem starts with searches and collections, where Bridge must have to build tables of file data from its database.

     
    |
    Mark as:
1 2 Previous Next
Actions

More Like This

  • Retrieving data ...

Bookmarked By (0)