LR3 not writing metadata to xmp

Preferences set to automatically write changes to xmp file. LR3 has stopped writing changes to xmp.
When I choose a thumbnail and click the "!" in upper right corner + click "Retry Metadata Export", I get this message: "Could not write metadata. Your disk has less than 1 gigabyte of space left".
This is correct, as there is 200mb free space on the particular disk, but I would think this would be sufficient. So question is: how much free disk space do I need for LR3 to continue to automatically write metadata to xmp?

From the message you have received and the statement made in the requirements for running LR on the Lightroom home page
minimum1GB of available hard-disk space
it would seem likely that 1 GB is the minimum. However I would suggest rather a great amount of free hard disk space is required in order for LR to function efficiently. But the minimum is pretty clear.Once you go below this you will experience problems and not just with writing metadata to file, but writing changes to the catalog itself if that is located on a disk with less than the minimum requirements The metadata once written takes up very little space, but the process of writing it can require space on disk for temporary files etc. Just make sure you have lots of spare capacity on any drive you use with LR.

Similar Messages

LR3 does not find metadata from XMP sidecars that EM2 does

I use Image Ingestor. When I ingest RAW files and view them in LR3 all the metadata applied using Image Ingester II is visible in LR3. When I ingest my older JPEG files II places the metadata into a XMP sidecar in the same folder with the same name as the file. LR3 seems to ignore these XMP files as it does not show ANY of my metadata except that from the JPEG EXIF from the JPEG file itself.
EM2 reads the XMP files and properly handles the metadata.
Googling turns up quite a few people with this issue.
My understanding is that LR3 is supposed to treat the XMP with precedence over the image file metadata but it does not seem to do this. Is there an option to be set?
This is an example XMP
<x:xmpmeta xmlns:x="adobe:ns:meta/" x:xmptk="3.1.1-112">
   <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#">
<rdf:Description rdf:about=""
            xmlns:dc="http://purl.org/dc/elements/1.1/">
         <dc:format>application/vnd.adobe.photoshop</dc:format>
         <dc:subject>
            <rdf:Bag>
               <rdf:li>pbr</rdf:li><rdf:li>steam</rdf:li><rdf:li>emerald funfest</rdf:li>
            </rdf:Bag>
         </dc:subject>
         <dc:description>
            <rdf:Alt>
               <rdf:li xml:lang="x-default"></rdf:li>
            </rdf:Alt>
         </dc:description>
         <dc:creator>
            <rdf:Seq>
               <rdf:li>Paul Pavlinovich</rdf:li>
            </rdf:Seq>
         </dc:creator>
         <dc:title>
            <rdf:Alt>
               <rdf:li xml:lang="x-default">Emerald Funfest 2010</rdf:li>
            </rdf:Alt>
         </dc:title>
         <dc:rights>
            <rdf:Alt>
               <rdf:li xml:lang="x-default">© Paul Pavlinovich</rdf:li>
            </rdf:Alt>
         </dc:rights>
      </rdf:Description>
<rdf:Description rdf:about=""
            xmlns:photoshop="http://ns.adobe.com/photoshop/1.0/">
         <photoshop:TransmissionReference></photoshop:TransmissionReference>
         <photoshop:Instructions>Contact Paul Pavlinovich for permission to use</photoshop:Instructions>
         <photoshop:Credit></photoshop:Credit>
         <photoshop:Source></photoshop:Source>
         <photoshop:Headline></photoshop:Headline>
         <photoshop:City>Melbourne</photoshop:City>
         <photoshop:State>Victoria</photoshop:State>
         <photoshop:Country>Australia</photoshop:Country>
         <photoshop:AuthorsPosition></photoshop:AuthorsPosition>
         <photoshop:CaptionWriter></photoshop:CaptionWriter>
         <photoshop:Category></photoshop:Category>
         <photoshop:SupplementalCategories>
            <rdf:Bag>
               <rdf:li></rdf:li>
            </rdf:Bag>
         </photoshop:SupplementalCategories>
         <photoshop:DateCreated></photoshop:DateCreated>
      </rdf:Description>
<rdf:Description rdf:about=""
            xmlns:Iptc4xmpCore="http://iptc.org/std/Iptc4xmpCore/1.0/xmlns/">
         <Iptc4xmpCore:CreatorContactInfo rdf:parseType="Resource">
            <Iptc4xmpCore:CiAdrExtadr></Iptc4xmpCore:CiAdrExtadr>
            <Iptc4xmpCore:CiAdrCity>Emerald</Iptc4xmpCore:CiAdrCity>
            <Iptc4xmpCore:CiAdrRegion>VIC</Iptc4xmpCore:CiAdrRegion>
            <Iptc4xmpCore:CiAdrPcode>3782</Iptc4xmpCore:CiAdrPcode>
            <Iptc4xmpCore:CiAdrCtry>Australia</Iptc4xmpCore:CiAdrCtry>
            <Iptc4xmpCore:CiTelWork></Iptc4xmpCore:CiTelWork>
            <Iptc4xmpCore:CiEmailWork>paulpATsteamengine.com.au</Iptc4xmpCore:CiEmailWork>
            <Iptc4xmpCore:CiUrlWork>www.steamengine.com.au</Iptc4xmpCore:CiUrlWork>
         </Iptc4xmpCore:CreatorContactInfo>
         <Iptc4xmpCore:CountryCode></Iptc4xmpCore:CountryCode>
         <Iptc4xmpCore:SubjectCode>
            <rdf:Bag>
               <rdf:li></rdf:li>
            </rdf:Bag>
         </Iptc4xmpCore:SubjectCode>
         <Iptc4xmpCore:IntellectualGenre></Iptc4xmpCore:IntellectualGenre>
         <Iptc4xmpCore:Scene>
            <rdf:Bag>
               <rdf:li></rdf:li>
            </rdf:Bag>
         </Iptc4xmpCore:Scene>
         <Iptc4xmpCore:Location>Emerald</Iptc4xmpCore:Location>
      </rdf:Description>
<rdf:Description rdf:about=""
            xmlns:mediapro="http://ns.iview-multimedia.com/mediapro/1.0/">
         <mediapro:Status></mediapro:Status>
         <mediapro:Event></mediapro:Event>
         <mediapro:People>
            <rdf:Bag>
               <rdf:li></rdf:li>
            </rdf:Bag>
         </mediapro:People>
         <mediapro:CatalogSets>
            <rdf:Bag>
               <rdf:li></rdf:li>
            </rdf:Bag>
         </mediapro:CatalogSets>
      </rdf:Description>
<rdf:Description rdf:about=""
            xmlns:xapRights="http://ns.adobe.com/xap/1.0/rights/">
        <xapRights:Marked>True</xapRights:Marked>
        <xapRights:UsageTerms>
            <rdf:Alt>
               <rdf:li xml:lang="x-default">All rights reserved</rdf:li>
            </rdf:Alt>
         </xapRights:UsageTerms>
         <xapRights:WebStatement></xapRights:WebStatement>
      </rdf:Description>
   </rdf:RDF>
</x:xmpmeta>


An update... if I change metadata in EM2 and force it to write it back to the XMP then LR3 can synchronize and suddenly has meta
data for the image.
The XMP after the change in EM2 is
<x:xmpmeta xmlns:x="adobe:ns:meta/" x:xmptk="3.1.1-112">
   <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#">
<rdf:Description rdf:about=""
            xmlns:dc="http://purl.org/dc/elements/1.1/">
         <dc:format>application/vnd.adobe.photoshop</dc:format>
         <dc:subject>
            <rdf:Bag>
               <rdf:li>pbr</rdf:li><rdf:li>steam</rdf:li><rdf:li>emerald funfest</rdf:li>
            </rdf:Bag>
         </dc:subject>
         <dc:description>
            <rdf:Alt>
               <rdf:li xml:lang="x-default"></rdf:li>
            </rdf:Alt>
         </dc:description>
         <dc:creator>
            <rdf:Seq>
               <rdf:li>Paul Pavlinovich</rdf:li>
            </rdf:Seq>
         </dc:creator>
         <dc:title>
            <rdf:Alt>
               <rdf:li xml:lang="x-default">Emerald Funfest 2010</rdf:li>
            </rdf:Alt>
         </dc:title>
         <dc:rights>
            <rdf:Alt>
               <rdf:li xml:lang="x-default">© Paul Pavlinovich</rdf:li>
            </rdf:Alt>
         </dc:rights>
      </rdf:Description>
<rdf:Description rdf:about=""
            xmlns:photoshop="http://ns.adobe.com/photoshop/1.0/">
         <photoshop:TransmissionReference></photoshop:TransmissionReference>
         <photoshop:Instructions>Contact Paul Pavlinovich for permission to use</photoshop:Instructions>
         <photoshop:Credit></photoshop:Credit>
         <photoshop:Source></photoshop:Source>
         <photoshop:Headline></photoshop:Headline>
         <photoshop:City>Melbourne</photoshop:City>
         <photoshop:State>Victoria</photoshop:State>
         <photoshop:Country>Australia</photoshop:Country>
         <photoshop:AuthorsPosition></photoshop:AuthorsPosition>
         <photoshop:CaptionWriter></photoshop:CaptionWriter>
         <photoshop:Category></photoshop:Category>
         <photoshop:SupplementalCategories>
            <rdf:Bag>
               <rdf:li></rdf:li>
            </rdf:Bag>
         </photoshop:SupplementalCategories>
         <photoshop:DateCreated></photoshop:DateCreated>
      </rdf:Description>
<rdf:Description rdf:about=""
            xmlns:Iptc4xmpCore="http://iptc.org/std/Iptc4xmpCore/1.0/xmlns/">
         <Iptc4xmpCore:CreatorContactInfo rdf:parseType="Resource">
            <Iptc4xmpCore:CiAdrExtadr></Iptc4xmpCore:CiAdrExtadr>
            <Iptc4xmpCore:CiAdrCity>Emerald</Iptc4xmpCore:CiAdrCity>
            <Iptc4xmpCore:CiAdrRegion>VIC</Iptc4xmpCore:CiAdrRegion>
            <Iptc4xmpCore:CiAdrPcode>3782</Iptc4xmpCore:CiAdrPcode>
            <Iptc4xmpCore:CiAdrCtry>Australia</Iptc4xmpCore:CiAdrCtry>
            <Iptc4xmpCore:CiTelWork></Iptc4xmpCore:CiTelWork>
            <Iptc4xmpCore:CiEmailWork>paulpATsteamengine.com.au</Iptc4xmpCore:CiEmailWork>
            <Iptc4xmpCore:CiUrlWork>www.steamengine.com.au</Iptc4xmpCore:CiUrlWork>
         </Iptc4xmpCore:CreatorContactInfo>
         <Iptc4xmpCore:CountryCode></Iptc4xmpCore:CountryCode>
         <Iptc4xmpCore:SubjectCode>
            <rdf:Bag>
               <rdf:li></rdf:li>
            </rdf:Bag>
         </Iptc4xmpCore:SubjectCode>
         <Iptc4xmpCore:IntellectualGenre></Iptc4xmpCore:IntellectualGenre>
         <Iptc4xmpCore:Scene>
            <rdf:Bag>
               <rdf:li></rdf:li>
            </rdf:Bag>
         </Iptc4xmpCore:Scene>
         <Iptc4xmpCore:Location>Emerald</Iptc4xmpCore:Location>
      </rdf:Description>
<rdf:Description rdf:about=""
            xmlns:mediapro="http://ns.iview-multimedia.com/mediapro/1.0/">
         <mediapro:Status></mediapro:Status>
         <mediapro:Event></mediapro:Event>
         <mediapro:People>
            <rdf:Bag>
               <rdf:li></rdf:li>
            </rdf:Bag>
         </mediapro:People>
         <mediapro:CatalogSets>
            <rdf:Bag>
               <rdf:li></rdf:li>
            </rdf:Bag>
         </mediapro:CatalogSets>
      </rdf:Description>
<rdf:Description rdf:about=""
            xmlns:xapRights="http://ns.adobe.com/xap/1.0/rights/">
        <xapRights:Marked>True</xapRights:Marked>
        <xapRights:UsageTerms>
            <rdf:Alt>
               <rdf:li xml:lang="x-default">All rights reserved</rdf:li>
            </rdf:Alt>
         </xapRights:UsageTerms>
         <xapRights:WebStatement></xapRights:WebStatement>
      </rdf:Description>
   </rdf:RDF>
</x:xmpmeta>

Bridge CS3 not writing metadata to JPEG files

For the last couple of months (without my noticing until a couple days ago) all JPEG files that I have edited using Bridge CS3 (on Windows XP) do not have the metadata built into the file. Here are the symptoms: use "File Info" to edit the metadata for a JPEG file (i.e. add a title, description, copyright info, etc.), all appears normal, but if you do any of the following, the metadata you entered disappears:
- duplicate (the metadata does not exist in the duplicate file)
- move or copy to another folder
- open in Photoshop or any other software that can read metadata (File Info shows none of the metadata you entered)
- rebuild the cache for the folder
Strangely, the metadata still appears with the file when you look at it in Bridge as long as you don't do any of the above.
This is really awful as I've put a lot of time into entering this metadata for hundreds of files. Older files (pre-Nov 08) don't have this problem and the metadata is "sticky" and doesn't get deleted. So, somehow my Bridge CS3 got corrupted along the way.
Has anyone experienced this and more importantly -- do you have a solution? I've tried reseting all Bridge settings (but that of course purged the cache and deleted all my metadata.)

Hey,
There are various date/time fields shown in properties panel in Organizer. The dates mentioned in general section are read from OS whereas the dates in EXIF field are read from image's EXIF data. In EXIF data there are three date/time fields-
1. Date time- This date/time info shows date modified of EXIF properties. So when you are writing a tag into imags's IPTC, you are doing some change in EXIF data. Hence this date should change to date when you are writing a tag into IPTC.
2. Date time original - Represents date time when a image was shoot.
3. Date digitized - Represents the date when the image was digitized (in digital camers there is hardly some delay between an image is shoot and it is digitized. So this field is always same as date original).
So, in your scenario, Date time in EXIF should change whenever you are writing any tag into its IPTC.
Please let me know if you need more info on it.
~Andromeda

Photoshop Elements 10 Organizer not writing metadata to files

Trying to use Photoshop Elements 10 Organizer to update date taken and add tags to picture files. Organizer is supposed to write/update the original file properties with this updated/new metadata, however, it seems to be pretty haphazard. I've tried selecting pictures and using the menu option to "Write keyword tag and properties info to photo" (CRTL + W). It processes and states it is updating the files, however, after it completes, you can access the source file in Windows Explorer and view properties but none of the changes (date info or tags) has been updated in the file.
Adobe support has been not been helpful simply pointing me to a knowledge article on metadata which basically tells you to use the same commands I'm already performing. Posting here to see if anyone has other suggestions.

Hey,
There are various date/time fields shown in properties panel in Organizer. The dates mentioned in general section are read from OS whereas the dates in EXIF field are read from image's EXIF data. In EXIF data there are three date/time fields-
1. Date time- This date/time info shows date modified of EXIF properties. So when you are writing a tag into imags's IPTC, you are doing some change in EXIF data. Hence this date should change to date when you are writing a tag into IPTC.
2. Date time original - Represents date time when a image was shoot.
3. Date digitized - Represents the date when the image was digitized (in digital camers there is hardly some delay between an image is shoot and it is digitized. So this field is always same as date original).
So, in your scenario, Date time in EXIF should change whenever you are writing any tag into its IPTC.
Please let me know if you need more info on it.
~Andromeda

5 stars not showing up on other computers when importing images that have been worked on. Catalogues settings include write metadata to xmp keywords do show up though

our working group usually one team member imports and completes job in lightroom 5 . All settings on team computers include write metadata to xmp. Key words show up if another team member adds the images to their catalogue but the 5 stars don't show up.
We use the 5 stars to show images that were worked on and complete.
Would love to sort this issue out as we rely on being able to see the star rating not just keywords.

[Sorry for the delay in getting back.] Of the three files you included in the Dropbox .zip, 2 had no rating, and 1 had a 5-star rating (*research*.dng). So indeed, the rating didn't get written to those two files and wouldn't show up when they were imported into another catalog.
A couple of suggestions:
1. Triple-check that the option Automatically Write Changes Into XMP is set in Catalog Settings > File Handling in everyone's Lightroom.
2. After someone sets the rating, check the thumbnail in Library grid mode -- does it have a badge in the upper-right corner indicating the metadata needs to be updated? If it does, then that means the metadata isn't getting written immediately back to the file:

Metadata not writing to jpgs

We keep all of our photos on a Windows Home Server 2011 shared folder.
Previously, we kept all our photos in a WHS v1 shared folder and it did not exhibit these issues.
The issue:
Metadata not writing to jpgs
We manage all our photos with Adobe Lightroom 3 and it is set to write metadata to a file immediately, which it does intitally or after a new import (We
edit our photos with ratings first, which writes to the file).
Any change after the first metadata write the "!" or "Up Arrow" appears and indicates that metadata has been changed externally. Even after you select
overwrite settings the "!" or "Up Arrow" stays.
If we select a batch set of photos and right click and navigate to Save Metadata...Lightroom will try to write and finish, but none of the changes get
applied to the photo.
Metadata will write if we manually save metadata to each individual file, but the "!" or "Up Arrow" still appears.
If the files are located on a local drive, Lightroom will continue to make metadata changes to the file.
I feel this is a permissions issue. Has anything regarding file permissions changed from WHS v1 to WHS 2011?
Homegroup on WHS 2011 was turned on, but is now disabled.
Any thoughts on how Lightroom gain the proper permissions to keep writing to a file?
Also, since I turned off Homegroup there are permissions for a user Account Unknown. Should this be there?

LR is accessing the file system with the credentials of your user account - so the first step is to verify that your user account has the proper permissions on your WHS (usually FullControl on the share and Read, Write, Modify on NTFS permissions).
I'm not familiar with WHS but I think Homegroup is the workgroup that hosts your user accounts - I would turn this back on then you should see the name of that Account Unknown user

Error when Writing Metadata to Files in Bridge (Mac) but not in Bridge (PC)

We get an error when writing metadata to files in Bridge (Mac) but not in Bridge (PC). In the same drive and folder, the PC can successfully write a keyword to a file on the PC, where the Mac returns an error. I have researched this at the Adobe Knowledgebase, but their answer seemed to indicate it was a global issue, and we don't see that behavior on the PC.
The client is a Mac of course, and the server volume is a Windows share volume. The Mac is bound to AD, and the domain\username and username formats have both been tried when logging in, but you receive the error in both.
Any help would be appreciated.
Thanks!
Rich Oliver

Hi, I'm having the same problem using FreeNAS (which uses Samba and Netatalk in the backend), but I tried with both AFP and SMB on Mavericks and Yosemite, I still have the same issue. I think it might be a timing issue with how lightroom interact with a slower write delay using network shares. I suggest you also chime into this thread: Lightroom 5 can't write metadata to DNG files I really hope this is resolved as this is impacting my productivity as I moved my workflow to my Macbook with a shared NAS.

DNG file modification date not changed by writing metadata?

I use LR 2.7 on Windows XP.   To my surprise, I just noticed that writing metadata updates (e.g., new keywords) from LR to the DNG files does NOT appear to update the file modification date, which suggests obvious issues for backup strategies (yes, I understand that a changed modification date introduces other backup issues).   I have verfifed that the metatdata does indeed change in the DNG files, so I am mystified.   Can someone shed some light on this?   Thanks.
js
www.johnshorephoto.com

Yes, I explicitely invoke "save metadata to file".   Furthemore, I have checked the behavior by (a) modifying DNGs in LR; (b) saving the metatdata to the DNG; (c) creating a new LR catalog and importing the revised DNGs.    The metadata changes do show up in the re-imported DNGs (and the metadata field "Metadata Date" correctly shows the recent change). Morevover, the file sizes do change (wth the metadata changes) even though the modification dates shown in windows explorer do not change.
However, I just redid the experiment to double check, and discovered an important clue - the mysterious behavior occurs when the DNG files are on a NAS device (in particular a Netgear ReadyNAS Duo.   To summarize:
     - When the DNG files are on a local hard drive, the file modification dates change as expected
     - When the DNG files are non local (i.e., on the network but on a NAS device), the file modification dates do not change even though the file sizes do change;
What's more, I see the same behavior when accessing the DNGs via Adobe Bridge (CS5) - i.e., if I change the metadata, I'm asked if I want to apply the metadata changes to the DNG, and I say yes (and confirm by looking via Bridge at a copy of the changed file).   On a local disk, the file modificaiton dates change (as do the modification date displayed in Bridge), but if the files are on the NAS, the modification dates do not.
Any additional thoughts?
js

Error writing metadata when Importing Lr 2.7 catalog in Lr 3 final

Hi,
I imported (and sucessfully converted) my Lr 2.7 Catalog in Lr3 final but now, all my photos have this little icon that says " Error writing metadata "
Why?
Thx!

According to Martin Evening in his Lightroom 2 book p. 178, "If you see the icon shown in Figure 4.74 [the !], click to open the dialog box where you can either choose Import Setting from Disk if you think the external settings are right, or choose Overwrite Settings if you think the Lightroom catalog settings are the most up to date."
If you did not edit these images in another program like Camera Raw some unknown event caused Lightroom to indicate that the files were edited in another program. In this case you probably do not want to include this edit. It will probably work out if you choose Overwrite Settings which will keep the settings that you have in the LR database, disregard the changes from outside LR, and remove the !.
If you edited these images in another program and you want to keep those changes, choose Import Settings from Disk to bring the external settings into the LR database.
If you want to write the LR settings to the DNG files go to Metadata > Save Metadata to File or (Ctrl-S). I strongly recommend saving LR settings to the file. Others disagree. In the Catalog Settings under Metadata, check Automatically Write Changes to XMP, if you prefer this to be done automatically.
Whatever you do, be sure to backup your LR database, at least two or three times, and be sure that all of you images are backed up.
Follow the above procedures by doing a few files at a time, and check that you are getting what you want before doing them all.

Not Writing Captions to IPTC???

When sorting my images, I need to add; caption, keywords, copyright notice, copyright URL, source, and author.
Until now I have always done this using two pages in the File Info Panel; Description and IPTC status.
Since upgrading to CS3, all of the libraries I am submitting to claim my images do not have captions in the IPTC. All the have is the image filename in it's place.
Is Bridge now writing to XMP instead of IPTC?
If I go to the description tab, and type 'young woman' in the 'description' field, then 'young woman' also appears under the 'description' heading in the 'IPTC content' tab indicating that it has written to IPTC. Yet still my captions are not being uploaded with my images? :S
Any ideas?

Hi Curt, thanks for your response! on my end there is no problem. I can see all the info fine. It just seems that for some unknown reason Adobe prefers to store their metadata in XMP as opposed to the worldwide standard of IPTC. And there is no option to change it either.
I am looking into software called iMatch now!

Lighroom 3 writing metadata to image files?

Hi,
I have been wondering why my backups (differential) weregetting larger than they should, and I noticed that some of the files (.psd and .jpg, and mayde few .tiff) were modified. Interestingly, I do not see this happening to cr2-files, that I mostly use. After trying to figure out what's going on I noticed that corresponding xmp-files were modified also. This is not the issue due to their small size, but still I had not edited images that were changed for quite a while.
Change that I see in xmp-files is rather large, and presumably related to Adobe's change in xmp-data structure. Eg.
<x:xmpmeta xmlns:x="adobe:ns:meta/" x:xmptk="Adobe XMP Core 5.3-c007 1.136881, 2010/06/10-18:11:35
">
<x:xmpmeta xmlns:x="adobe:ns:meta/" x:xmptk="Adobe XMP Core 4.2-c020 1.124078, Tue Sep 11 2007 23:21:40
">
In addition to the sample above, whole xmp structure is changed. So I presume that maybe LR is writing metadata chages to xmp in the background?
What I find disturbing is that when checking changed jpg files, I saw the similar data written into the jpg files also (files were created with oldish Canon 20D, and not edited for quite a while). These are examples from changed jpg-files (not the same from which the abone xmp-data change was taken, but similar change is visible in the corresponding XMP):
Also jpg-file from offset 0x04 was changed from "50 60" to "51 18". Also offset 0x10 was changed (16 bits).
I have Lightroom configuration option "Include develope settings in Metadata Inside JPEG, TIFF and PSD Files" not selected. The option "Automatically write changes to XMP" is selected. To my understanding neither of these should not have impact to the issue. Is there something else I should check?
Change is made most likely by Lightroom 3.5 version, and has not occurred with previous versions. I have not notices this happening with 3.6, but I have been using it only few weeks. Is this known issue with previous version 3.5, or am I missing something obvious?
System running is Windows 7 pro 64bit. I have not have any issues with LR lately, except crashes that I white about a week ago.
Any advice on what's going on?

So I was missing something. Thank you Hal.
I had not realised that XMP goes inside of actual image files with those file types. Obviously my new backup routine spotted that, as I was on backuping only modified/new files.
I would much prefer that also with above mentioned file types XMP-data would be stored in sidecar files instead of modifying the original file. To support this there are two arguments that I think are valid:
1) modification of the file is always risky (and spesifically, with image originals I prefer to avoid that),
2) modification leads to the fact that "smarter" backup strategies relying on "full backup" supported with differential or incremental backups lead to unnecessary long backuptimes and media consumption.
That said, I prefer to have XMP-data also outside of the catalog so that other tools can also utilise it (further, in addition to the catalog with sidecars I have sort of failover approach, and some of you may now say "belt and syspenders" after mentioning backups...).
Is there a way to have all file types to utilise sidecars rather that modifying original file?

Bridge error "there was an error writing metadata"

If I want to add keywords to my RAW files in PS adobe Bridge I get regularly (usually) a message as follows "there was an error writing metadata nr img 1326 CR2". How can this be resolved ? iMac
grts
ingridMG

How can this be resolved ?
It might have several reasons but my best first guess is that you want to much at the same time?
When adding keywords Bridge is not capable on multitasking. When the activity bar starts to spin (bottom left in bridge window) you best wait until the first bunch has finished.
My second guess is about XMP files, Bridge does not write metadata in the Raw file itself but to a separate XMP file with the same file name but different extension (.xmp). By default the XMP files are hidden in Bridge (you can see them in the Finder folder structure, the moment you make changes in ACR, add rating and or labeling as well as metadata and keywords the XMP files get's created) and using the menu view/ show hidden files/ they will show in the content window.
It might be you have a locked file or not the correct permission. So also use your Apple Disk Utility to check and repair permissions.

Bridge cs3 mac 2.1.1.9 will not append metadata

I've been using Bridge CS3 for a long time now on my iMac 2Ghz Core Duo (Tiger OS X 10.4.11) with 2 GB of RAM
I have been using the same metadata template for a year, and have updated to Bridge 2.1.1.9
Starting today, whenever I try to append metadata to a 1.6 Gb folder of images (Nikon D300 jpg's), I get the error message "There was a problem writing metadata to...."
I have held the option key at Bridge startup , purged the folder cache, and checked the "Use Software rendering" option in preferences
I have tried appending metadata to a smaller folder with the same results
I use Bridge every day to tag and keyword photos - please help me to get this working again

I split the files into 2 folders and tried to append metadata on a folder that contained 99 files totaling 568MB
That did not work
I removed the file that was first reported as "problem writing metadata..", purged the folder cache and tried again - the error occurred on the very next file numerically
The error always seems to start with the highest-numbered file in the folder
I have also tried replace metadata and that does not work
I have also tried to enter metadata manually and then apply it to all the images in a folder - that does not work either
Maybe this 2.1.1.9 update has broken metadata somehow?

"Error writing metadata to" message and extended attributes

After being frustrated by this error message in Bridge while trying to apply keywords to various image files I finally took the time to investigate, and I think I found the cause of the issue. In a nutshell, if the extend attribute "com.apple.FinderInfo" has not yet been created for a given file, then this message appears.
The start of the puzzle was that some files would take the keyword and others would not. After observing identical permissions on files that worked and files that did not, I noticed that in a terminal listing of the files in question, some files had extended attributes and some did not (extended attributes are identified by an @ symbol when running ls -la in a terminal window. For example:
-rw-rw-rw-@   1 mike staff 26131946 21 Jan 23:56 120114-133059-4612.cr2
-rw-rw-rw-    1 mike staff      5710 21 Jan 22:42 120114-133059-4612.xmp
-rw-rw-rw-@   1 mike staff 27200794 17 Jan 17:52 120114-133145-4613.cr2
-rw-rw-rw-    1 mike staff      5702 21 Jan 22:42 120114-133145-4613.xmp
-rw-rw-rw-@   1 mike staff 26973498 21 Jan 23:07 120114-133149-4614.cr2
-rw-rw-rw-@   1 mike staff      6648 21 Jan 23:19 120114-133149-4614.xmp
As you can see, the file called 120114-133145-4613.xmp has not extended attribute, but the file 120114-133149-4614.xmp does. The former throws an error when applying a keyword, the latter does not.
So I dug a bit further and it appears that when the file attribute called com.apple.FileInfo is missing from an xmp file, metadata cannot be witten. The contents of this extended attribute for a working XMP file look like this
$ xattr -l 120114-133058-4611.xmp
com.apple.FinderInfo:
00000000 54 45 58 54 43 52 61 77 00 00 00 00 00 00 00 00 |TEXTCRaw........|
00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000020
According to specs I found googling, the first 4 bits identify the file type (TEXT), and the next four identify the file creator (CRaw). IOW no file-specific info seems to be present.
So as a test, I simply copied the contents of com.apple.FinderInfo from a file that had it to a file that didn't. Once the file that didn't received the new attribute, metadata writes worked. The command I used for the copy was
xattr -wx com.apple.FinderInfo "`xattr -px com.apple.FinderInfo 120114-133534-4633.xmp`" 120114-133041-4602.xmp
It also appears that this metadata is written by Bridge based on some unknown trigger, because occasionally during my investigation a file that previously would not take metadata suddenly did, and once I knew to look for extended attributes, in every case the file in question suddenly had com.apple.FinderInfo extended attribute.
So...I'm not sure if this is a bug in finder or in bridge, but it is definitely a bug and needs to be addressed.
...Mike

I have tried purging the cache, and also deleting it entirely and starting over, to no effect.
Mike
just did a quick try and don't know if it is the right way.
Using Lightroom 3.6 (not very familiar with Lightroom) and Bridge 4.0.5.11 on MacOSX 10.6.8
I randomly choose some CR2 files that where somewhere on my system and copied them to a new folder. Imported them in Lightroom and added some rating and a few keywords. (with setting metadata to XMP file active)
Then went to Bridge and opened the same folder. After caching Bridge showed the info as filed in Lightroom. Added some keywords to all files without problem. Went back to Lightroom (restarted it and had to choose read metadata menu. After this no problem to read new keywords form Bridge. But they only show in Italic because the have not been made persistent in the Bridge keyword list, however this is as expected behavior.
Tried a develop setting and that was also showing in Bridge correctly. Went a few times back and fort (files in Lightroom showing a memo with Exclamation sign top right of the in Bridge changed thumbnail asking for reading metadata).
Is this about the way you mean to describe?
And when having set Automatically export changes to XMP have you set this option in both Lightroom and Bridge (this s to be found in the Camera Raw preferences 'save image settings in: sidecar XMP')
And there are a few things to refresh also in Bridge besides the deleting of the cache file, you can also delete the Bridge plist file from the user library preferences and restart Bridge holding down option key and chose reset preferences. And did you run the check and repair permissions for your system also?
I tried to look in terminal but could not find a way to use the ls -la command on the folder with changed files so no comparing on that side I'm afraid.

Error writing metadata to any file except jpegs

Hi all,
A coworker and I have been assigned the job of keywording all the photos in our database. We aren't photographers and are only messing with the keyword metadata on the photos.
But we've been having a consistent problem with Bridge CS4. When I attempt to add keywords to any file format except jpeg, it gives me an error message "Error writing metadata to " and the filename. Then to make matters even worse, Bridge continues trying to add the metadata to the same images over and over again until I do a forced shutdown.
We're running Bridge on a network with exported cache. The only thing I have found as a possible solution is a permissions setting problem, but I can't find any way to check on that.
Any help you can offer would be great. Thanks!

I had this same problem. This was the solution for me in my CS4.
Go to Bridge
Go to Preferences
Go to Metadata
Make sure IPTC and Keywords are checked.
This will allow you to add keywords to your metadata in bridge.
Here it is not checked:
Here it is checked:

LR3 not writing metadata to xmp

Similar Messages

Maybe you are looking for