Copy link to clipboard
Copied
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]
Copy link to clipboard
Copied
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.
Copy link to clipboard
Copied
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?)
Copy link to clipboard
Copied
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
Copy link to clipboard
Copied
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
>
Copy link to clipboard
Copied
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
>
Copy link to clipboard
Copied
Dear Melissa,
1.) Exactly the same camera model (Nikon D7000), same sd-card.
2.) I will try the next time, I "fixed" all files the way I described
earlier.
This is a single-user machine, there is only one account, it has admin
rights and user account control is off. I do not own another win7-machine.
3.) Next time.
Best Regards,
Simon Jiménez
Am 02.09.2011 09:55, schrieb Jingshu Li:
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 ( mailto:jingshu@adobe.com )
Bridge QE
>
Copy link to clipboard
Copied
Dear Melissa,
I got this error again. Copying to Desktop does make no difference.
I uploaded a file, and when I download it again (uploading via ftp,
downloading via http), the error still exists.
Please verify that error: http://simon.jimenez.at/upload/D70_9360.JPG
The picture was made using a D7000 and a SanDisk SDHC Card. Several
other files of the same series (I did this just to test this out) were
unaffected.
Best Regards,
Simon Jiménez
Am 02.09.2011 09:55, schrieb Jingshu Li:
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 ( mailto:jingshu@adobe.com )
Bridge QE
>
Copy link to clipboard
Copied
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
Copy link to clipboard
Copied
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
Copy link to clipboard
Copied
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.
Copy link to clipboard
Copied
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.
Copy link to clipboard
Copied
Any progress?
Copy link to clipboard
Copied
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
Copy link to clipboard
Copied
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.
Copy link to clipboard
Copied
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?
Copy link to clipboard
Copied
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
Copy link to clipboard
Copied
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.
Copy link to clipboard
Copied
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
Copy link to clipboard
Copied
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.
Copy link to clipboard
Copied
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?
Copy link to clipboard
Copied
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.
Copy link to clipboard
Copied
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.
Copy link to clipboard
Copied
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.
Copy link to clipboard
Copied
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