EX CAM metadata problem ? Files being lost

Hi all,
I am not a particularly experienced editor but i have been using PP CS5 for the last few months to edit some EX CAM (EX) files that i shot on an EX3.
The strange thing is...though everything has being going fine up to now...in the last couple of days...PP CS5 has started losing track of some of my EX CAM clip files. For example, I have a 1 hour 20min file that i have been working with (not very intensively...just doing some titling and so forth)...it was shot in an EX3 and the mp4 files spanned across two cards when it was shot. Up to now...dragging in the first "EX clip" in the series has predictably also brought in all the other "clips" and the whole file has played seamlessly as one file and in the right order. But now, when i save and shut down my PC, the next day when i start up the project, the file has diagonal gray bars across portions of it in the sequence timeline and PP seems unable to find those clip portions of the file. Down the bottom of the PP screen I get the little yellow progress bar graph saying "CONFORMING mp4"...But after it finishes this process, it still fails to find the missing parts of the EX clip.
Some times it even starts to get confused and gets the clips in the wrong order (eg clip section 6 appears as section 1).
It seems to me that PP is either not reading the metadata correctly, or the EX metadata has been corrupted. I have checked the BPAV folders and everything seems there (though i didn't open up the CUE files). I also checked the mp4's and all the raw mp4 clips are there and playable.
Can anyone tell me what is happening ? If this continues, my whole project will be screwed....i have thousands of EX clips and it would take months to drag them all into the project and order them manually.
The drive that the files are on is a Western Digital Black Caviar and it is not a networked drive. I am doing very lightweight editing with very few effects and there have been no performance issues with the system (no drive speed issues, no RAM issues, no video card issues so far). I am running Win 7 Ultimate 64 bit and I should mention i am running the accelerated GPU workaround "hack" with an Asus EN-GTX260 1GigDDR5
Cheers,
Pete

Hi,
My problem is solved...thought i would post the simple fix.
All i had to do was start a completely fresh project, import the same problematic EX3 assets into that new project (via Import command) and then drag that clip into the timeline and instantly all EX clip links were restored ...and here's the weird part, they were restored not just in the new project but in ALL other projects that used those EX3 assets. ie. by doing this, my original project was also repaired. Don't ask me why...I'm just happy.
There is another thread on the same topic overe here ( http://forums.adobe.com/message/3362918#3362918 ) if anyone is still having problems.
Pete

Similar Messages

Is there a solution to the data/time camera metadata problem?

After a lot of testing I've nailed down a serious flaw with Lightroom, and I'm wondering if people have any sort of solution, either from within Lightroom or externally.
When Lightroom is used to export JPEGs, the exported files have the correct Image EXIF data stamped in the Date/Time Original and Date/Time Digitized fields - it matches the date/time of the RAW file, which is exactly what you'd want and expect.
What it doesn't set correctly though is the JPEG file Created, and file Modified dates - they are set as the date/time the JPEG export was done from Lightroom. There are many applications that sort based on the last modified date of the JPEG, and it's illogical that Lightroom wouldn't have the JPEG file metadata match up with the EXIF data. I can't think of a single scenario where you'd want to have two different time/data stamps in the image that you just exported.
Using ACDSee I can batch change the JPEG file Created and file Modified dates to match the EXIF data. It's an added step I shouldn't have to do, but I can do it. What I *can't* change in batch mode with ACDSee is the Camera Date/Time time - which, you guessed it, is stamped with the time that the JPEG was *created* during the export, not the time that the camera was set for when the RAW file was captured, which is what it SHOULD be set to. It should be stamped with the EXIF date/time original data. I think I already know the answer to this, but is there any setting in Lightroom that addresses this issue?
I've seen others recommend EXIFtool but using a command line tool isn't what I consider a reasonable suggestion. Are there any other tools that might help me here?

Jason -
 
 You mentioned that the CreateDate wasn't set correctly in your files. For my JPGs exported from LR, based on Canon CRW raws, the CreateDate does match the DateTimeOriginal. ExifTool is reasonable enough for me; here is a sample output of ALL the date/time related fields in one of my exported JPGs.
 
 
[File] File Modification Date/Time : 2007:07:28 11:25:31
 
 [EXIF] Create Date :
          &#16 0;     2007:07:21 15:29:14
 
 [XMP]
 Date/Time Original :
style='mso-spacerun:yes'>        &#16 0;2007:07:21 15:29:14-05:00
 
 [XMP]
 Date/Time Digitized :
style='mso-spacerun:yes'>        2007 :07:21 15:29:14-05:00
 
 [XMP]
 Modify Date :
style='mso-spacerun:yes'>        &#16 0;       2007:07:28 11:25:30-05:00
 
 [XMP]
 Metadata Date :
style='mso-spacerun:yes'>        &#16 0;     2007:07:27 14:35:04.062-05:00
 
 
 
 As discussed by other posters, I agree that the ModifyDate needs to reflect the most recent activity on this particular file, and is not related to the original capture time.
 
 Gary

Serious autosaving problems (data being lost)

I wasn't sure which was the appropriate forum section to post this, but I figure I'd start here since I noticed this probelm after upgrading to Mavericks.
I do most of my work for my law practice on my MacBook Air. Except for open cases and files, most of my documents are archived on a 1TB drive installed in my Mac Pro. That hard drive is shared on my office network. The office network is simple: just a ATT U-Verse modem connected to an Airport Extreme and a couple of ethernet hubs. My MacBook Air normally is connected over wifi.
Anyway, I rarely access the archived files, but when I do, I open them in Pages, and I may or may not make some changes. Yesterday, I tried editing a couple of .pages documents. Pages natually tried to autosave, but it told me that another application was using the file and the changes could not be saved. It gave me the option to "save anyway," which I selected, but that failed and the error message that popped up insisted that I close the docuemnt. This happened for both of the documents I was working on, however... on one document only the changes were lost, but on the other docuemnt something was corrupted and the document could not be opened after that.
Like I said, I'm running the latest version of Mavericks on both my MacBook Air and the Mac Pro. The shared storage drive in the Mac Pro hasn't been formatted or anything like that since Snow Leopard.

Anyone?

Metadata in Bridge CS3 lost after editing NEF file in Capture NX2

Entered keywords and metadata in Bridge CS3, edited NEF file in Capture NX2 and then all metadata in Bridge got lost even if I did not edit any metadata in Capture.
Original Bridge metadata are still saved in XMP file but Bridge does not show them nor can search or sort photos by them.
Is it a Bridge bug or is it connected with any settings?
Win XP, Bridge CS3 2.1.1.9, Capture NX2 2.2.0, Nikon D300
Will appreciate any help, thanks a lot.

First I renamed photos in Bridge - sidecar XMP files were created with the new filename already, added some keywords and metadata in Bridge. Edited photo in Capture but not changed the name again - the result was the Bridge does not show edited metadata and keywords anymore even all those info are still saved in sidecar XMP file. Capture apparently does not change XPM in any way.
It looks like all the problems are connected with renaming files in Bridge before editing them in Capture as if Bridge cannot read XMP after Capture added its own info in NEF file.

Problems adding metadata to file

Hello,
I've recently stopped automatically writing metadata to file, and now do it manually after I have edited a folder of
photos by command-s or clicking on the down arrows which indicate the metadata hasn't been written yet
But I have two problems:
1) When I select a few photos, either by shift-click or command-A, then do a command-s or click the
arrow to save metadata, it only saves it to the first photo (I thought I could save more than one photo at a time?)
2) After I save metadats to file, and the arrow goes away, and I exit the folder I've been working on,
if I go back to the folder the arrow(s) often come back, even though I've done nothing more (no more
editing/keywording etc). In fact the arrows are back as soon as I open the folders?
I then save metadats to file again, and same thing happens - it's driving me crazy. Any ideas
Many thanks, Roy

Thanks, that seems to have worked (fingers crossed). It seems to me that the file is writing metadata back to the
catalogue though, where it came from? This confuses me.
I have also seen something on an Adobe link (I forgot to mention I convert my files to DNG in Lightroom) that states:
'If you're working with a DNG file, choose metadate>update DNG previews & metadata to save metadata changes to the file and also generate a preview based on the current raw processing settings'
I've never seen this before, and maybe it's what I should do each time instead of command-s or metadata>read metadata from file? I've got a couple of LR5 books, including the one by Martin Evening, but pretty sure this isn't mentioned, or I've missed it. Can anyone clear this up as I'm worried I might be doing something wrong here?
Roy

Save Metadata to File Problem

This is really puzzling me .... In Catalogue Settings, I have 'Automatically write changes into XMP' NOT ticked. When I want to save, I Select All and then 'Save Metadata to File' . However, most of the time this only saves the 'Most Selected' image, it does not create/write to XMP for all the selected files? However, I know this is meant to save to all the selected files and I also know that sometimes it does/has saved all the XMP files for me. I cannot figure out why sometimes it saves all the files and sometime only the 'most selected' ? I have tried in both Library and Develop Modules. Is there a reason for this or is it some kind of bug?
I'm using Lightroom Ver. 3 on a Mac. But I also used to have the same problem on Version 2 as well.
Many Thanks

Switch to Grid view - anything you do in Grid view will always apply to all selected images.

Hi, I have a new laptop and would like to syncronise my iphone with iTunes (which I have installed again). But my old laptop has died so I could not transfer any media files, etc. Can I simply connect my iPhone to the laptop without any data being lost?

Hi, I have a new laptop and would like to syncronise my iphone with iTunes (which I have installed again). But my old laptop has died so I could not transfer any media files, etc. Can I simply connect my iPhone to the laptop without any data being lost?
Many thanks in advance!

you have a new phone and a new comp and you want to restore to your old data ?!
I can't think of anything but icloud, and what was purchased via itunes

For the second dime in a yearish,following update download my computer crashed.after installing maverick four times got a semi working computer but my backup disc is trashed and working files seem lost.anybody else get this problem or is it selective?gerr

for the second time in a yearish,following download my computer crashed and burned.four attempts to reinstall maverick resulted in a semi-working computer but my back up disc trashed and working files seem lost.Anybody else get this problem and how regularly or is it a selective event?
gerry

It is not safe to publish your email address in an open forum, so I've asked the hosts to remove them. Your post is here for anyone to see and if someone has a solution, they will post an answer, so there is no need for an email address.

"Date Modified" for all files being changed if "Automatically write to XMP" is on

Recently upgraded from LR3 (v3.4.1) from LR2 on OSX 10.6.8 and have always had Catalog Settings > Automatically write changes into XMP turned on.
When browsing existing JPG files in my Library (no Develop changes, no keywording, no Presets, no Import), LR3 is writing to disk — i.e., when I look at files in Finder, almost every viewed file’s “Date Modified” is being set to today’s date and time. (It actually creates a .swp file, then changes it's name back to .jpg)
This is really bad, as it's making it impossible for me to use Finder to figure out when I last worked with a file, it is triggering needless Time Machine and Backblaze backups, and unnecessarily churning my disk.
If I turn off "Automatically write..." this behavior stops. Per David Marx at thelightroomlab.com, I tried turning off this preference, manually doing a "Save Metadata to File" for all files, letting that complete, then turning the preference back on. This does not solve the problem.
Per a suggestion at photoshop.com, I used ExifTool to see what changes LR was writing to a sample file; from the diff below, you can see that LR is adding a bunch of new fields as well as moving other fields around. But my point is that LR3 should never overwrite a file on disk if all I am doing is browsing thru them.
Is anyone else seeing this? Any ideas would be greatly appreciated!
-- David
diff Exif5609_original Exif5609_update
2c2
< FileName: DSC_5609_original.JPG
> FileName: DSC_5609_update.JPG
5,6c5,6
< FileModifyDate: 2009:11:27 21:32:54-08:00
< FilePermissions: rwxr-xr-x
> FileModifyDate: 2011:08:07 22:06:47-07:00
> FilePermissions: rw-r--r--
27a28,29
> ShutterSpeedValue: 1/200
> ApertureValue: 7.1
55d56
< SerialNumber: 3209521
75d75
< Lens: 18-200mm f/3.5-5.6
185,188d184
< UserComment:
< SubSecTime: 00
< SubSecTimeOriginal: 00
< SubSecTimeDigitized: 00
211a208,299
> XMPToolkit: Adobe XMP Core 5.2-c004 1.136881, 2010/06/10-18:11:35
> CreatorTool: Ver.1.00
> MetadataDate: 2011:08:07 22:06:47-07:00
> SerialNumber: 3209521
> LensInfo: 18-200mm f/3.5-5.6
> Lens: 18.0-200.0 mm f/3.5-5.6
> ImageNumber: 26634
> RawFileName: DSC_5609.JPG
> SavedSettingsName: Import
> SavedSettingsType: Snapshot
> SavedSettingsParametersVersion: 6.4.1
> SavedSettingsParametersProcessVersion: 5.0
> SavedSettingsParametersWhiteBalance: As Shot
> SavedSettingsParametersIncrementalTemperature: 0
> SavedSettingsParametersIncrementalTint: 0
> SavedSettingsParametersExposure: 0.00
> SavedSettingsParametersShadows: 0
> SavedSettingsParametersBrightness: 0
> SavedSettingsParametersContrast: 0
> SavedSettingsParametersSaturation: 0
> SavedSettingsParametersSharpness: 0
> SavedSettingsParametersLuminanceSmoothing: 0
> SavedSettingsParametersColorNoiseReduction: 0
> SavedSettingsParametersChromaticAberrationR: 0
> SavedSettingsParametersChromaticAberrationB: 0
> SavedSettingsParametersVignetteAmount: 0
> SavedSettingsParametersShadowTint: 0
> SavedSettingsParametersRedHue: 0
> SavedSettingsParametersRedSaturation: 0
> SavedSettingsParametersGreenHue: 0
> SavedSettingsParametersGreenSaturation: 0
> SavedSettingsParametersBlueHue: 0
> SavedSettingsParametersBlueSaturation: 0
> SavedSettingsParametersFillLight: 0
> SavedSettingsParametersVibrance: 0
> SavedSettingsParametersHighlightRecovery: 0
> SavedSettingsParametersClarity: 0
> SavedSettingsParametersDefringe: 0
> SavedSettingsParametersHueAdjustmentRed: 0
> SavedSettingsParametersHueAdjustmentOrange: 0
> SavedSettingsParametersHueAdjustmentYellow: 0
> SavedSettingsParametersHueAdjustmentGreen: 0
> SavedSettingsParametersHueAdjustmentAqua: 0
> SavedSettingsParametersHueAdjustmentBlue: 0
> SavedSettingsParametersHueAdjustmentPurple: 0
> SavedSettingsParametersHueAdjustmentMagenta: 0
> SavedSettingsParametersSaturationAdjustmentRed: 0
> SavedSettingsParametersSaturationAdjustmentOrange: 0
> SavedSettingsParametersSaturationAdjustmentYellow: 0
> SavedSettingsParametersSaturationAdjustmentGreen: 0
> SavedSettingsParametersSaturationAdjustmentAqua: 0
> SavedSettingsParametersSaturationAdjustmentBlue: 0
> SavedSettingsParametersSaturationAdjustmentPurple: 0
> SavedSettingsParametersSaturationAdjustmentMagenta: 0
> SavedSettingsParametersLuminanceAdjustmentRed: 0
> SavedSettingsParametersLuminanceAdjustmentOrange: 0
> SavedSettingsParametersLuminanceAdjustmentYellow: 0
> SavedSettingsParametersLuminanceAdjustmentGreen: 0
> SavedSettingsParametersLuminanceAdjustmentAqua: 0
> SavedSettingsParametersLuminanceAdjustmentBlue: 0
> SavedSettingsParametersLuminanceAdjustmentPurple: 0
> SavedSettingsParametersLuminanceAdjustmentMagenta: 0
> SavedSettingsParametersSplitToningShadowHue: 0
> SavedSettingsParametersSplitToningShadowSaturation: 0
> SavedSettingsParametersSplitToningHighlightHue: 0
> SavedSettingsParametersSplitToningHighlightSaturation: 0
> SavedSettingsParametersSplitToningBalance: 0
> SavedSettingsParametersParametricShadows: 0
> SavedSettingsParametersParametricDarks: 0
> SavedSettingsParametersParametricLights: 0
> SavedSettingsParametersParametricHighlights: 0
> SavedSettingsParametersParametricShadowSplit: 25
> SavedSettingsParametersParametricMidtoneSplit: 50
> SavedSettingsParametersParametricHighlightSplit: 75
> SavedSettingsParametersSharpenRadius: +1.0
> SavedSettingsParametersSharpenDetail: 25
> SavedSettingsParametersSharpenEdgeMasking: 0
> SavedSettingsParametersPostCropVignetteAmount: 0
> SavedSettingsParametersGrainAmount: 0
> SavedSettingsParametersLensProfileEnable: 0
> SavedSettingsParametersLensManualDistortionAmount: 0
> SavedSettingsParametersPerspectiveVertical: 0
> SavedSettingsParametersPerspectiveHorizontal: 0
> SavedSettingsParametersPerspectiveRotate: 0.0
> SavedSettingsParametersPerspectiveScale: 100
> SavedSettingsParametersConvertToGrayscale: False
> SavedSettingsParametersToneCurveName: Linear
> SavedSettingsParametersCameraProfile: Embedded
> SavedSettingsParametersCameraProfileDigest: D6AF5AEA62557FCE88BC099788BBD3CC
> SavedSettingsParametersLensProfileSetup: LensDefaults
> SavedSettingsParametersToneCurve: 0, 0, 255, 255
> IPTCDigest: d41d8cd98f00b204e9800998ecf8427e
228,230d315
< SubSecCreateDate: 2009:11:27 21:32:54.00
< SubSecDateTimeOriginal: 2009:11:27 21:32:54.00
< SubSecModifyDate: 2009:11:27 21:32:54.00
http://feedback.photoshop.com/photoshop_family/topics/lr3_date_modified_for_all_files_bein g_updated_when_browsing_photos_if_catalog_settings_automatically_write_changes_into_xmp_is /replies/6313647

clvrmnky wrote:
davidpope007 wrote:
Then when LR3 loaded my old LR2 images into memory, it "dirtied" the in-memory copy of the file by adding in these new LR3 XMP fields. Then, because I had "Automatically write XMP" on, it said "I better write these changes to disk".
Yuck. As a former software engineer, this is very bad software engineering.
It should wait until the user dirties the file (via Develop, keywords, etc.) before presuming to add a bunch of metadata fields that are unique to the new version of LR3.
Well, I'm a current software developer, and this is, really, a perfectly reasonable thing to do. It is a reasonable trade-off for a convenient feature required by a small subset of users.
Yes, in most cases the in-memory copy should "never" be dirtied unless the user makes a gesture of some sort, but like I said earlier, this option (once set by the user) sets up the situation where this gesture becomes implicit. This is a clear trade-off for the sake of convenience. And if the XMP is out of date and needs to be updated en masse, so be it.
The fact is, there is no easy way around this. Do we save up /every/ dirty buffer somehow until you make a gesture that /might/ require the XMP to be up-to-date before acting on that gesture? Now we have to worry about unflushed buffers if something goes wrong and the app exits. Do we save the buffers to the DB? Now we have to block some calls to make another blocking call to flush some or all of those to DB, and then write some or all of it out to one or more files. In what order? What if there is a gesture to have X files with up-to-date XMP and some or all of those are in unflushed buffers, unflushed DB writes or we have to wait for the DB.
As you can see, this is a transactionality nightmare, and the easiest and safest thing to get what the user wants (i.e., up-to-date XMP for the purpose of talking to a third-party XMP aware app) is to simply update the sidecar or XMP block in an atomic manner using the correct file IO. The file will have to change at some point, so it may as well be now.
[Thanks to both of you for your detailed replies. I am aware of the need for tradeoffs so when you say the approach taken is quite reasonable, I do believe you. I also apologize in advance for the length of the following and am extremely aware of the time it must have taken you to compose the above replies, but I'm going to add a bit more, if only for my own piece of mind and in hopes of coming up with a solution for my workflow.]
From my naive point of view, I was expecting the answer to be simply "don't raise the XMPDirtyFlag upon reading in a file". Obviously if your architecture requires you to "upgrade to latest XMP format" upon read, and another part of the system auto-detects "out of date XMP", then it's going to write those changes to disk.
But it didn't need to be designed that way. LR obviously has mechanisms to know when a user has made a change to XMP so it is able to write XMP changes to disk only when necessary.
The promise (to me) of "Automatically Write XMP changes to disk" was to auto-save my changes, and not those made for any internal (i.e., XMP versioning related) changes.
Perhaps the premise is that it is LR3's job to update an individual file's XMP to the latest version so that other XMP-aware apps can make use of it? I would argue that those third-party XMP-aware apps already have to know how to deal with all prior versions of XMP, so LR3 should just leave well enough alone.
You asked if my problem with your approach was that it was "inelegant"; not at all, it is based on my own perception of what I need from my workflow, so let me describe that so maybe we can find a better way:
* Part of the appeal of LR to me is that it preserves my original file as it came off the memory card, allowing me to move to a different workflow/toolset in 2025 if I choose to do so
* However, with all of changes contained in a single database file, I'm concerned about rare (but possible) corruption, so to mitigate this risk, I let LR backup my database weekly and it's also backed up continuously in the cloud via Backblaze
* Even with backups of the database, there is still a chance that I could lose changes made to individual files (e.g., LR corrupts the DB and I have to go back to last week's DB)
* Thus the appeal of the "auto-write to XMP" flag -- that way critical changes (develop, crop, keywords) are saved on a per-file basis; I liked the "automatic" part of this (as opposed to a manual save) because then I don't have to teach others in my family how to manually save XMP changes
* A nice side-effect of this setting is now when I use Finder to find a file and double-click on it to edit it in Photoshop, all my develop changes are right there; (in other words, I like the flexibility of not having to fire up LR in order to just invoke PS from within it); also when I use Bridge I see all the keywords there
* So with LR2, I had gotten used to what I thought was the best of all worlds -- autosave of changes at the file level via XMP + raw negatives untouched (i.e., Date Modified == the date I took the picture); this allows me to use operating-system-level tools -- Finder -- to locate/search for files
* Now I upgrade to LR3 and I'm finally now understanding that a concept "XMP versioning" is going to result in changes to many, but not all my files. (That's something else that's annoying about this issue -- I open up the Grid and browse a folder of files, and only seemingly random ones I've cursored over seem to get written to disk -- if it's so urgent that LR3 update the XMP, then it should do it for all the files in the catalog or at least in that directory)
Here's a screenshot from Finder of what I see everytime I look at this folder:
* So now I have to assume that each new version of XMP and/or LR is going to touch my files on disk. Sigh.
* What I don't like about this is that it is ruining the promise of "untouched raw negative". Yes, the image data is untouched -- which I agree is most of the benefit; but the file has been touched.
* Perhaps you might empathize a bit more if you imagined that someone went thru all your source code or Word files and randomly changed the date to "today" because you upgraded compilers or moved to Word 2011.
I agree all of this would be solved by having an XMP sidecar file for JPGs, but you indicate that's not going to happen.
You've also alluded to the solution of "resetting the Date Modifed" to it's original value -- which I believe is what Finder does when you move or copy a file -- but that that is fraught with issues as well. I believe you when you say there are issues, but again the naive part of me wonders why that soultion would be so bad...
I just thought of another potential solution -- turning on Date Created in Finder -- but it turns out that's changed, too.
I am really at a loss as to what to do and would welcome your suggestions.
Thanks again and kind regards,
-- David

Bug: Keywords behave incorrectly after "Read Metadata from File"

(Happens in LR3.4 RC and probably also in previous versions... but I am not sure if it happened in LR2)
The problem seems tro be somthing like de-sync of database status and what we see on the screen.
1) Let's say we have a photo with keyword "abc"
2) Click in the Keyword List on the arrow around the "abc" keyword to show only photos with this keyword (single one), leave the filter on this settings
2) Save Metadata to File
3) Edit XMP in an external application, add new keyword "def"
4) Read Metadate from File
5) Now what happens is: The photos disappers from the screen as if it lost the "abc" keyword (weird), but if you look at the Keyword List, the "abc" keyword has still 1 photo attached to it. Also, if you release the filter and find the photo, it clearly has the "abc" and "def" keywords in the Keywording panel. And you can search for this keyword in the text filter (works correctly), but if you click on the arrow around the "abc" keyword, the photo is not shown.
6) If you restart the Lightroom, it will work correctly again.
I have an own application that is able to modify the XMP and the modifications may not be perfect, but in my opinion, this shouldn't happen when reading the metadata. If any developer is reading this, I can supply a file with original and changed metadata for debugging.
It would be great it this could be resolved.
Thanks!

Please do report your find with the details you state (well done!) here: https://www.adobe.com/cfusion/mmform/index.cfm?name=wishform
Thanks.........

Errors when writing metadata to files on Windows Server

Good day!
I have an iMac running OSX 10.9 (Maverick) and Lightroom 5.2.
My catalog is on the local iMac drive, and the images are on SMB shared drive (handled by Windows 2012 server).
I decided to do the final layout of my album using InDesign, and for that I needed to access to images using Bridge. So selected all the images (the rated once...) and issue a Metadata/Save command.
The system came back with errors on many of the files (such as Photos are read only, and unknown errors).
Retrying to save the metadata on image that was flagged with an error usually (but not always) worked.
I tried to select save the metadata for few (6) images in a time, many times it was ok, but sometimes, one or two of them failed (and retrying again usually solved the problem).
It looks to me like a timing related issue.
Any ideas?
(After spending about an hour on this, I have exported the images to my local drive...). In general I don't have similar problems with other apps.
Any ideas?
Yuval

I Yuval
I'm experiencing more or less the same behavior (see Read-only error when writing metadata to file over network (Synology DS1315+ using AFP) ). For me however, the problem is more pronounced if I use the AFP protocol and is better (I think as you described) if I use SMB (all done on a Synology DS1315+). With SMB it most often works but in very rare cases I also get the "read only" message!
Do you have solution to this? Or are you stuck as I am?
Cheers, Chris

Cross References Being Lost InDesign CS4

I am setting up cross-references in a multiple
document book using InDesign CS4 (Windows).
When our editors open the files using InCopy CS4
some of the cross-references are broken (little red flag icon appears).
I've relinked the cross-references several times but everytime
an InCopy user opens the file the cross-references are lost again.
The sources and destinations are within the same document.
I'm using Paragraph number as the cross-referencing method.
Does it have something to do with the InDesign files being part of a Book?
Any help would be great.
Thanks, Bill

wsterli wrote:
I am setting up cross-references in a multiple
document book using InDesign CS4 (Windows).
When our editors open the files using InCopy CS4
some of the cross-references are broken (little red flag icon appears).
I've relinked the cross-references several times but everytime
an InCopy user opens the file the cross-references are lost again.
The sources and destinations are within the same document.
I'm using Paragraph number as the cross-referencing method.
Does it have something to do with the InDesign files being part of a Book?
Any help would be great.
Thanks, Bill
It's possible that being a book component file that's separated from its other component files has some effect.
I believe that x-refs look for a coded marker to keep up-to-date, not the paragraph number, so even if the numbers get out of whack because they continue from a previous file, this shouldn't cause the problem.
I don't know how x-refs appear in IC. Is it possible to hover over the error indicator and see an explanation of the problem? If so, please post the message.
Do the x-refs become resolved when you return the document to the book in ID?
HTH
Regards,
Peter
Peter Gold
KnowHow ProServices

Approx 700 Files being deleted from file server (server 2003) without permission

Hello,
We had a problem with files being deleted from our file server.
We lost approx. 700 files across approx. 40 directories from the file date codes between Nov. 30 2014 and Dec 3, 2014. All files before this date were not touch.
Our Dec. 1 backup had all of the files. Our Dec. 5 backup only have files before Sept. 1 2014 and after Dec. 3, 2014.
My question is how can this happen without going to each directory and sorted my date cade and delecting files from this date range.
Does anyone have any other ideals on how this could of happen?
Thank You
Bert

Hi,
I suggest you enable file system auditing to find out the cause of this issue.
AD DS Auditing Step-by-Step Guide
http://technet.microsoft.com/en-us/library/cc731607(v=WS.10).aspx
Planning and Deploying Advanced Security Audit Policies
http://technet.microsoft.com/en-us/library/ee513968(v=WS.10).aspx
Best Regards,
Amy
Please remember to mark the replies as answers if they help and un-mark them if they provide no help. If you have feedback for TechNet Subscriber Support, contact [email protected]

Error: can't update, file is lost

I downloaded the standalone version of the update and I don't know where it is. How do I launch it? Seems to have disappeared inside my hard disk somewhere.
So I downloaded another one and after a half gigabyte it says it can't save the update. Presumably the first one is preventing the second one from being saved.
I tell you what, I have so many problems with Mac these days I feel like I should switch back to Microsoft (after 9 years). Pardon me for being irritable, but one problem after the other, and you think you solved one and it causes more problems.

Gnarlodious wrote:
I downloaded the standalone version of the update and I don't know where it is. How do I launch it? Seems to have disappeared inside my hard disk somewhere.
So I downloaded another one and after a half gigabyte it says it can't save the update. Presumably the first one is preventing the second one from being saved.
I tell you what, I have so many problems with Mac these days I feel like I should switch back to Microsoft (after 9 years). Pardon me for being irritable, but one problem after the other, and you think you solved one and it causes more problems.
You only mention one problem, and it's not Apple's fault. You downloaded a file and lost it.
When you downloaded the second one, that should have shown you where the first one is.
If the second download failed, it's possible your HD is full. A download of an identical file automatically results in a (1) being appended to the file name so there is no conflict or error.
Clearly you have some other problem.
Did you look in your downloads folder?
Did you use Finder to search for it?
You launch it by double-clicking it after you find it, which is always the way to launch a downloaded image/app.
Again, if you have other problems with your computer, you should address and resolve them before updating. Never update a computer that is not working properly, unless the update is specifically directed at an existing problem.

ERROR WHEN SAVING METADATA TO FILE

how do I fix this

tiffs are supported, but you probably have some incompatible metadata in your tiffs (assuming tiffs are not otherwise corrupt). Consider logging bug report and sending example of offending tiff to Adobe.
Were all those tiffs updated using a common application (other than Lightroom)?
Consider using exiftool to read/write metadata and see how that works. Assuming it is what I think it is (and not an unsupported camera problem or other legit incompatibility), you may even be able to fix the problem using exiftool, but definitely save problem files to support bug report to Adobe.

EX CAM metadata problem ? Files being lost

Similar Messages

Maybe you are looking for