Metadata Writing

I selected 51 photo images and applied a metadata template to all.
How long should the metadata writing process require? My 3.5 Ghz 2 GB ram XP SP2 system has been cranking along for about 10 minutes. the caption at lower left of the Bridge window keeps flashing "___items ___selected ____MB (writing metadata to [the same file name])". Wondering if maybe the system has been overloaded??

After about 20 m. of the described behavior, I terminated Bridge, opened images in PS-CS4 and found (to my delight) that all photos had the correct metadata written to them.

Similar Messages

All my audio (WAV) files got destroyed by "Metadata writing in progress" error. Help please?

I am running Adobe Premiere CS6.03 which is the most current update I believe. I am running Windows 7 64bit with 16GB RAM 3.60 GHz quad core.
When I tried to save my project I got the error "Metadata writing in progress (2 files pending). If you quit before writing is complete, data will be lost. Are you sure you want ot quit? "
I waited 30 minutes but nothing changed. So I just accepted and exited. Then when I reopened the project all the sound looked like this:
They are WAV files from a Zoom H4N. The video files work perfectly. For some reason it's just the audio files that got destroyed. The actual original WAV files itself are fine it's just that particular sequence, in fact I can pull the original audio files from the project tab into the same sequence and they will play. It would take me ages to reconstruct the audio sequence piece by piece. I tried "Replace Footage" which didn't work and I tried linking the media all over again which didn't work. I've been working on this project forever. Is there any fix for this?

If you have "save media cache next to originals when possible" ticked in your preferences then you might need to delete the .pek files that Premiere generates from the folder that your wav files are in. Premiere will make a new one, and I've found this has fixed similar audio issues that I've had in the past.
Otherwise, open a new project and then import the sequence from your old project into it, and see if that fixes it.

Bridge CS4 Metadata Writing Errors

When trying to write info into one field (IPTC Source field) on numerous image files (Select all), Bridge will not respond, it acts as if it is applying the metadata then when files are deselected, nothing. The metadata is not entered in any of the images. Anyone? They are all JPG files, granted there are a lot of them, about 200, but I have been able to make this work in the past and lately bridge has been remarkably quirky in this regard. I have been having similar issues with the keyword function as well.
eudaimonx

May have figured this out,...there was a rogue .pdf in the same folder as the jpgs, removed this file to another folder and all seems to be well. Not sure why .pdf messes metadata writing up though...hmmm

Metadata writing in progress (n files pending).... error

After updating to the latest version of the Premiere Pro last week, everytime I am closing the project I now get a "Metadata. Metadata writing in progress (n files pending). If you quit before writing is complete, data will be lost. Are you sure you want to quit? Yes/No" error window. Please see a screenshoot attached for one of such errors.
What is interesting, is that no matter how much time i give it the process is never complete.

dkitsov wrote:
After updating to the latest version of the Premiere Pro last week, everytime I am closing the project I now get a "Metadata. Metadata writing in progress (n files pending). If you quit before writing is complete, data will be lost. Are you sure you want to quit? Yes/No" error window. Please see a screenshoot attached for one of such errors.
What is interesting, is that no matter how much time i give it the process is never complete.
So the metadata writing in Premiere is fairly involved.
It tries to write metadata in the background asynchronously, but only when the file isn't being touched by something else in the application or by some other application. What you're experiencing is potentially (I can't say for sure yet) where these 23 background metadata writing tasks never finished, or someone else never let go of the file. If that someone else is Premiere, it is definitely a bug (which is my current guess).
Are you able to provide which file types these 23 files are, and what sort of drive/volume they're on (e.g. local/external USB/firewire/SSD/etc).
And since a number of other posters are mentioning that this started in 6.0.2 for them, is that the same for you?

Metadata writing in progress...error

I am getting this error:
"Metadata writing in progress (1file pending). If you quite before writing is complete, data will be lost. Are you sure you want to quit?"
The program sits there for hours, one time over a day and nothing happens. I have to force quit. This is happening along with the infamous "unsupported or damaged file" error that folks are getting when importing RED footage.
It would be awesome if anyone could find a way to fix this...ADOBE...hello?
VT

This is a documented issue that we're working on resolving. Thanks for the info.
Peter Garaway
Adobe
Premiere Pro

LR4 - Hierarchical Keyword Metadata Writing Problem

Having found a problem with LR4 in reading hierarchical metadata from photo files, I now seem to have found a similar problem when writing metadata to files.
As before, I use hierarchical keywords with the "/" character as the separator in the photo files metadata.
Let's say I assign the keyword "Christmas" to a photo. This actually has the hierarchy "Events/holidays/Christmas"
When I write out the metadata to the photo, I want, and expect, the hierarchical keyword string to be written: Events/holidays/Christmas.
Instead, what I get are three separate keywords written out separated by commas: Events,holidays,Christmas.
This is pointless - LR4 has just destroyed my keyword hierarchy and just given me a flat list of keywords.
Is this a bug, or is this indeed expected behaviour of LR4? Because if it's the latter, then LR4 is not going to work for me as a metadata editor.
Thanks

That's the expected behavior of LR 3 and 4. Some background:
There is no widely accepted industry standard yet for handling hiearchical keywords. (The Metadata Working Group has defined a standard, but I don't know of any application that has implemented it yet.)
LR stores hierarchical keywords in the XMP:HierarchicalSubject metadata field (a non-standard field recognized by LR and Bridge), with the elements of the hierarchy separated by "|", e.g. Events|Holidays|Christmas. In the industry-standard field XMP:Subject, LR only stores non-hierarchical keywords. You can control whether the containing keywords (e.g. Events and Holidays) are also stored in the XMP:Subject field with the keyword options Export Containing Keywords and Include On Export.
Other non-standard approaches store hierarchical keywords in the XMP:Subject field, with the elements separated by "|", ".", or "/". For compatability, LR will recognize those hierarchical keywords when it reads metadata, controlled by the options in Preferences > File Handling. But LR always writes out its hierarchical keywords using its own non-standard approach.
Perhaps in a few years, the industry will have converged on a standard and implemented it.

Best practice in writing xmp metadata?

I know to switch off the 'automatically write to xmp metadata' feature. But, after doing this, what is the best way to ensure the xmp metadata does actually stay up to date?
My understanding is that by switching the automatic writing back on, LR goes through the whole catalogue, comparing the data in its database with the data in the xmp files, and every time it finds something different, it copies from the database to the xmp. However, there would seem to be two problems with this. i) it's extremely slow, because it's such a big job, and (b) presumably any changes made elsewhere, eg in ACR, will be overwritten.
The alternative seems to be to right click on the folder while in library mode and select "save metadata". However, for some unknown reason, this is unbelievably slow. What prompted me to write this message is that nearly an hour ago, I did this with a folder of 78 files, and it's still churning away. In that time, I've had time to log on to this forum, read a few messages, do a search to see if there is anything helpful, and then write and edit this. I don't dare try this with the folders I have with three hundred photos in!
The LR catalogue is in a partition with hardly anything else in it, on a different physical drive from LR itself. It gets defragged more frequently than the defrag utility thinks it needs to be. During metadata writing and many other operations, the CPU maxes out at 100% yet only about 75% of my 1GB memory is used.
Is there anything I can do?
I'm on an old-ish PC and am not in a position to upgrade (please - any messages just saying I need a newer computer are not going to be any help :-) ). Any other help would be appreciated.

Thanks, Mel. You just posted as I was writing the previous message!
I think you nailed it. The 78 pictures, I did by right-clicking on the folder name in the right-hand fly-out panel in library and selecting 'save metadata' (hope the choice of words here is clear!). I've just tried the ctrl-a, ctrl-s technique you describe, and it whizzed through a folder of 127 photos in no time.
So, you're right - there appears to be a bug.
One more problem - there was an error in saving to the tifs in the folder. A separate problem which I'll look at tomorrow.
Back to the other part of my original question. What is the most efficient way to keep the xmp data up-to-date? Considering that there's massive scope for human error in having to remember to save manually all the time, this can't, surely, be the best way to do it. What do people generally do, and has anyone evolved a 'best practice'?

Metadata in progress

can you explain me what this message means?
Metadata in progress (2 files pending). If you quit before writing is complete, data will be lost.

Probably best to read this first:
http://forums.adobe.com/thread/1064315
Or, more specifically:
"... the metadata writing in Premiere is fairly involved.
It tries to write metadata in the background asynchronously, but only when the file isn't being touched by something else in the application or by some other application. What you're experiencing is potentially (I can't say for sure yet) where these 23 background metadata writing tasks never finished, or someone else never let go of the file. If that someone else is Premiere, it is definitely a bug (which is my current guess).
Are you able to provide which file types these 23 files are, and what sort of drive/volume they're on (e.g. local/external USB/firewire/SSD/etc).
And since a number of other posters are mentioning that this started in 6.0.2 for them, is that the same for you?"

Continuing Metadata update problems

LR 2.1 final.
Catlog Setting: Automatically write changes into XMP.
Files are mostly JPEG.
I imported photos, adding metadata during the import. I then went through all photos, setting rating and adding keywords. Yet, a day later (leaving LR running all night), "Metadata Status" and "Metadata Date" are not displayed on any of these photos until I manually "Save Metadata to file". I have verified that I cannot see the keywords or other metadata with another application until I have saved the metadata, and once saved, the metadata are there.
Also, once saved, changing the metadata does not always cause LR to save the changed metadata to the file. Sometimes it does. Sometimes not. Very confusing and frustrating! And the ". . ." indicator in Grid view on photos with unknown or unsaved metatdata status is no longer shown, so a quick glance does not tell me if the metadata is saved or not.
Does anyone have any answers? Are my expectations incorrect? Is LR 2.1 broken?

Because of very slow performance with automatic writing enabled, they made the metadata writing very lazy. So it might take a long time before it gets updated. Are you sure you need to have the metadata written to your originals? It is far better to leave your originals completely untouched and just export copies when you need them.

PSE7, PS CS4, Organizer, Bridge, Camera Raw, Canon DPP

I'm trying to develop a process for using the various tools available to easily browser through a shoot's photos, zoom as needed, choose favorites, make any changes, etc.
I have PSE7/Organizer, Bridge/PS CS4, Camera Raw for both PSE7 and PS CS4, and Canon DPP. I owned PSE7 first, and I like it's backup features as well as the keyword/album and browsing interface, but I'm finding it may not be good for fast processing of a shoot's photos when they are RAW.
I'm shooting in RAW and I'm finding that zooming RAW images in Organizer is not possible beyond whatever preview image is present. Instead, I must open the image, which causes Camera Raw to open. Once in Camera Raw, I can zoom with greater control.
But what I notice is that using Bridge may be better to use for browsing RAW images, especially if I desire to open them in Camera Raw for greater zoom control, touch ups or whatever. The reason is that it seems to take longer for PSE7's Organizer to open a photo in PSE7 and Camera Raw than it takes for Bridge to open the same in PS CS4 and Camera Raw.
Here are my findings:
First time open of RAW or DNG:
Organizer opening to PSE7/Camera Raw: 15 seconds.
Bridge opening to PS CS4/Camera Raw: 10 seconds.
Second time open of RAW or DNG:
Organizer opening to PSE7/Camera Raw: less than 10 seconds.
Bridge opening to PS CS4/Camera Raw: less than 5 seconds
"Second time open" means that I keep the relevant application open when I return to the organizer. For example, after PSE7 opens, I do not close it when returning to Organizer, and likewise, when returning to Bridge, I do not close PS CS4 when returning to Bridge. The above figures show Bridge can open a RAW or DNG photo into PS CS4 and Camera Raw faster in both the case of PS CS4 not already open, and when an instance of PS CS4 is already open.
In exploring all of this, I tried using DPP as my "Organizer" and it, of course, was the fastest at opening photos to its editor which has a few preset zoom positions. It does have a "Transfer to Photoshop" option but that takes 30 seconds and converts to a TIFF in a temp directory. So DPP seems like something to avoid unless there are RAW editing features which do not exist elsewhere.
Given the above, it seems the best process for me is to use PSE7's Organizer for the features I like (i.e., backup, keywords, albums), but use Bridge/PS CS4 when processing a shoot's photos for keepers. Then use Canon DPP only if it has something which I must use, or just like better.
Do my choices here make sense, where I'm not missing something? If there's a good link that discusses high-level process for dealing with a shoot's photos to find keepers, that would be great to know about.
I realize what's best for anyone really depends on each person's preferences/needs, so the questions I ask are seeking general answers given the limited information I've explained about what's important for me (i.e., going through photos quickly, having good zoom control for review, and being able to go to either PSE7 or PS relatively fast... my findings say that Bridge/PS CS4 seems best for this unless DPP has something I must utilize).
Thanks,
Tom

Barbara and George M, You both had answers, but only one can be selected as "Correct" ... I wish the forum allowed splitting that. I gave Barbara's answer the "correct" mark since it was first. George M, I clicked "Helpful Answer" on your response, but your info was much more than just "Helpful"... great tips on the import/download file/dir naming. I'll look into that.
I played around with Bridge/PS quite a bit more, and I'm sold on its way of doing things. I get it now. It stores all keywords with the files, so this removes the need for any organizer-proprietary/custom format databases for retaining such information. This is actually the way I prefer to work, with as much control and as close to the files as possible, or at least with enough info about the files so I can do the right backups, ensure I'm saving the information I add, and so forth. PSE7 has the benefit of allowing keywords without affecting the files, but that's not a big deal for me so long as the metadata-writing software in the products I use isn't buggy, destroying the file (I know, I know, have a backup!).
I really liked PSE7 because I was thinking in terms of an organizer maintaining non-photo data (i.e., keywords) as does PSE7, but since Bridge embeds the info as metadata in the photo file itself, it removes the need for that type of organizer. With that known, the issue of backups no longer needs to be organizer-centric. With Bridge, I know the files and folders themselves is effectively The database. That means I can use whatever I use for my normal backups, and things are actually much more manageable and understandable down that route. So the Bridge/PS route is not only more powerful and faster (in my experience on my laptop), but the Bridge-way of embedding the keywords in the file keeps me loosely coupled, actually completely decoupled from being reliant on an organizer-specific database and all that jazz.
Thanks for helping/clarifying with your feedback on this.
Tom

Create Folder with a category definition?

Hi,
Is there any way to attach a CATEGORY_DEFINITION to a folder in a worskpace?. I have only seen CATEGORY_CONFIGURATION attached. What I am trying to say, is there is any way to assign category attribute information to subfolder in a worksapce. Thanks in advance,
Igor.
Mensaje editado por:
user511556

I also need to accomplish the task of setting metadata attributes at the folder level. I do not believe that it is impossible. The Collaboration Suite web interface appears to do this very thing. It may be impossible using the oracle.ifs.fdk API, but that's just a weakness in the high-level API in my opinion. The data is being stored somewhere, that much is for sure.
If the oracle.ifs.fdk API is insufficient to handle this task, Oracle ought to support an alternate means to get the job done. This is a fundamental part of any useful document management system.
When examining the CONTENT schema in the database, it is obvious that both documents and folders support category instances in one form or another. It is also obvious that these two types of PUBLICOBJECTs are dealt with very differently in the database.
At the end of this post are given two PLSQL procedures and one function that will populate a document with a given ID with metadata for my own custom category called "File Metadata". The second procedure and the function are just helpers called by the first. You'll need to grant the CONTENT user select privileges on SYS.DBA_TAB_COLUMNS. This is how the procedure gets the names of the metadata attribute columns, which will be different for every custom category. Naturally, you will have to modify the parameters and procedure body to make it work for your own custom category, using the name of your category and your own metadata attribute names as well. If you run the SELECTs in a sql editor, you will see how the data is laid out in the CONTENT schema. Though the procedure does not indicate this, everything starts with the ODMV_PUBLICOBJECT view.
This procedure will not work for folders because the database layout for folder category attributes is different. I have yet to fully map it out, though I am deep into it. I will post a solution here when I find it.
If anybody already knows the solution, please don't hesitate to post it. This is a cry for help. The category structure for folders is very difficult to trace. The actual metadata values are very elusive. Here's what I have found thus far:
Let's say I have a folder whose ID is 958609. Here's the folder object itself, and all its child objects:
select *
from odmv_publicobject
where id = 958609
or securingpublicobject = 958609;
Some of these children are category override instances. In my system, category overrides are the rows with a CLASSID of 2646. If you look up this ID in ODMV_CLASSOBJECT, you will see that it is ADHOCCONFIGURATION. This is different from a document's category instance, which has a custom CLASSID which points to a custom category in the ODMV_METADATASCHEMACATEGORY view. We see a divergence between document and folder category implementation already at this point. This query gives me the "ad hoc" category instance for my folder:
select *
from odmv_publicobject
where securingpublicobject = 958609
and classid in (
select id
from odmv_classobject
where name = 'ADHOCCONFIGURATION'
Among the child objects of my folder lie some more interesting things. It appears that the metadata attributes themselves are to be found here. The following query finds them all. Note the similarity to the preceding query. The only thing that changed was the type of CLASSOBJECT we are looking for.
select *
from odmv_publicobject
where securingpublicobject = 958609
and classid in (
select id
from odmv_classobject
where name = 'METADATACATEGORYATTRIBUTEOVERRIDE'
order by id asc;
Now that I have these objects, it would seem like an easy task to look them up in whatever table they are stored in, and change the attribute values. But I cannot find this table (yet). This is where I am stuck. Any suggestions, please?
Another odd fact: if you change folder metadata, all subfolders will reflect the change. Documents, however, do not change. Folders appear to inherit parent folder category metadata unless it is explicitly changed. I think this behavior extends all the way up to the domain object itself. Perhaps the domain object holds a bit of the secret. The domain object is a PUBLICOBJECT just like folders, documents, users, etc.
Anyway, once this metadata attribute override table is found, it will be an easy matter to write PLSQL that can read and write folder metadata attribute values. Forget about oracle.ifs.fdk; it will not serve us here. As you can see, the official word is that it cannot be done, even though we can all see it works in Collaboration Suite, and we can see some of the implementation in the database.
The document metadata writing procedure:
PROCEDURE update_file_metadata (
p_docid IN NUMBER,
p_folderid IN NUMBER,
p_create_date IN NUMBER,
p_footer_number IN VARCHAR2,
p_to IN VARCHAR2,
p_from IN VARCHAR2,
p_entered_by IN VARCHAR2,
p_hardcopy_available IN VARCHAR2,
p_subject IN VARCHAR2,
p_revision_number IN VARCHAR2,
p_document_vendor IN VARCHAR2,
p_drawing_number IN VARCHAR2,
p_title IN VARCHAR2,
p_drawing_revision IN VARCHAR2,
p_drawing_sheet_number IN VARCHAR2,
p_drawing_vendor IN VARCHAR2
IS
l_metadata_id NUMBER(20);
l_category_id NUMBER(20);
l_displayname VARCHAR2(500);
l_query VARCHAR2(2000);
BEGIN
-- Get the category id for the named category
SELECT associatedschemaobject
INTO l_category_id
FROM odm_schemacategory
WHERE id IN (
SELECT id
FROM odm_metadataschemacategory
WHERE displayname LIKE 'File Metadata'
-- Find the metadata id.
find_metadata_id('File Metadata', p_docid, l_metadata_id);
-- Get the column names for the category metadata table.
-- The column names are the key to the ODMV_MDATAATTRSCHEMACATEGORY view.
l_query := '';
FOR rec IN (
SELECT column_name
FROM sys.dba_tab_columns
WHERE table_name = 'ODM_ECM_' || l_category_id
AND column_name not like 'ID'
) LOOP
-- Get the human-readable name of the attribute.
SELECT displayname
INTO l_displayname
FROM ODMV_MDATAATTRSCHEMACATEGORY
WHERE name = rec.column_name;
IF(l_displayname = 'Created/Received Date' AND p_create_date IS NOT NULL) THEN
l_query := l_query || rec.column_name || ' = ''' || escape_naughties(p_create_date) || ''',';
END IF;
IF(l_displayname = 'Footer Number' AND p_footer_number IS NOT NULL) THEN
l_query := l_query || rec.column_name || ' = ''' || escape_naughties(p_footer_number) || ''',';
END IF;
IF(l_displayname = 'To' AND p_to IS NOT NULL) THEN
l_query := l_query || rec.column_name || ' = ''' || escape_naughties(p_to) || ''',';
END IF;
IF(l_displayname = 'From' AND p_from IS NOT NULL) THEN
l_query := l_query || rec.column_name || ' = ''' || escape_naughties(p_from) || ''',';
END IF;
IF(l_displayname = 'Entered By' AND p_entered_by IS NOT NULL) THEN
l_query := l_query || rec.column_name || ' = ''' || escape_naughties(p_entered_by) || ''',';
END IF;
IF(l_displayname = 'Sealed Stamped Documents/Drawings Available' AND p_hardcopy_available IS NOT NULL) THEN
l_query := l_query || rec.column_name || ' = ''' || escape_naughties(p_hardcopy_available) || ''',';
END IF;
IF(l_displayname = 'Subject' AND p_subject IS NOT NULL) THEN
l_query := l_query || rec.column_name || ' = ''' || escape_naughties(p_subject) || ''',';
END IF;
IF(l_displayname = 'Revision Number' AND p_revision_number IS NOT NULL) THEN
l_query := l_query || rec.column_name || ' = ''' || escape_naughties(p_revision_number) || ''',';
END IF;
IF(l_displayname = 'Document Vendor' AND p_document_vendor IS NOT NULL) THEN
l_query := l_query || rec.column_name || ' = ''' || escape_naughties(p_document_vendor) || ''',';
END IF;
IF(l_displayname = 'Drawing Number' AND p_drawing_number IS NOT NULL) THEN
l_query := l_query || rec.column_name || ' = ''' || escape_naughties(p_drawing_number) || ''',';
END IF;
IF(l_displayname = 'Title' AND p_title IS NOT NULL) THEN
l_query := l_query || rec.column_name || ' = ''' || escape_naughties(p_title) || ''',';
END IF;
IF(l_displayname = 'Drawing Revision' AND p_drawing_revision IS NOT NULL) THEN
l_query := l_query || rec.column_name || ' = ''' || escape_naughties(p_drawing_revision) || ''',';
END IF;
IF(l_displayname = 'Drawing Sheet Number' AND p_drawing_sheet_number IS NOT NULL) THEN
l_query := l_query || rec.column_name || ' = ''' || escape_naughties(p_drawing_sheet_number) || ''',';
END IF;
IF(l_displayname = 'Drawing Vendor' AND p_drawing_vendor IS NOT NULL) THEN
l_query := l_query || rec.column_name || ' = ''' || escape_naughties(p_drawing_vendor) || ''',';
END IF;
END LOOP;
IF(l_query IS NOT NULL) THEN
l_query := 'UPDATE ODM_ECM_' || l_category_id || ' SET ' || l_query;
l_query := RTRIM(l_query, ',');
l_query := l_query || ' WHERE ID = ''' || l_metadata_id || '''';
-- DEBUG: Uncomment to see the query we have written.
--RAISE_APPLICATION_ERROR(-20102, l_query);
EXECUTE IMMEDIATE l_query;
END IF;
END;
PROCEDURE find_metadata_id (
p_category IN VARCHAR2,
p_docid IN NUMBER,
o_metadata_id OUT NUMBER
IS
BEGIN
SELECT id
INTO o_metadata_id
FROM odm_publicobject
WHERE securingpublicobject = p_docid
AND classid IN (
SELECT associatedschemaobject
FROM odm_schemacategory
WHERE id IN (
SELECT id
FROM odm_metadataschemacategory
WHERE displayname LIKE p_category
END;
-- Basically analogous to a perl untaint.
FUNCTION escape_naughties(
p_badstring IN VARCHAR2
) RETURN VARCHAR2
IS
BEGIN
RETURN REPLACE(p_badstring, '''', '''''');
END;

Unable to export: an internal error has occurred

Hi, everybody,
Just when I was trying to convince myself that I should NOT go back to LR2, no matter how ugly the new import interface is, I tried my first export and this is all I get:
- ping
- UNABLE TO EXPORT: AN INTERNAL ERROR HAS OCCURRED ?:0 ATTEMPT TO INDEX NIL VALUE
I am using Vista up to date on a 64 bit system
Anybody else having this problem? any solutions?
Why, oh, why, did I not stick to the old efficient and working LR2, the noise reduction filter lured me into this mess

Solution - try to limit the number of files you are exporting. I came to this forum as I was running into the same problem, but I worked it out for myself. It appears the ability to export multiple files is limited, either by number or by memory. I'm running Vista with 4GB, and I was limited to around 100 files at a time. So I broke my export into a number of smaller exports of around 100 files each, and it worked.
I tried the other solutions - syncing metadata, writing metadata to files, no plugins, etc., and none of those propositions worked. The only thing that worked was limiting the scope of the export.

What am I missing here: Canopus ADVC110 Footage vs. CS6?

My church uses the subject Canopus device to capture DV (avi) footage to hard disk. I've successfully edited this footage from this workflow for years in CS4 and CS5 (skipped 5.5). When CS6 arrived, I attempted to use it, but quickly switched back to CS5 due to the issue I am about to describe. I want to finally switch over to CS6 now (and to CC soon, I hope), so I very much want to understand what the issue is with CS6. Here's the issue:
I've narrowed this down to the original footage AVI files captured from the Canopus. As soon as PP begins to conform the footage, it hangs for a very long time. Initially, the small preview thumb displays an image. The conforming progress bar displays (but no progress). But the monitor displays the footage as offline. During this time, any click in the PP window yields a "(not responding)" suffix in the title bar. Eventually, given enough time, the video footage appears and scrubs, but without audio, the audio waveform, and with no conforming progress bar. There are no error messages during this time. Given the time consumed and lack of audio, I have not proceeded any further in the edit.
I suspect this is a x64 codec issue with the Canopus. Does anyone have experience with this workflow and this problem? Is the solution software or hardware? Do I need to replace the Canopus? If so, I need recommendations please.
Thank you very much.
HP z800
WIN 7 Pro x64
Nvidia Quadro FX 4800
24GB RAM
CS5 and CS6 Installed
Perry

New info: I do have another (HP z400, WIN7 x64) machine with CS6 that exhibits similar behavoir as the other with the Canopus footage. My user on this one is in the Admin user group. I don't get the "not responding" suffix in the title bar. But the conforming progress bar does not move. When I go to close PP, i get this message:
"Metadata writing in progress. Are you sure you want to exit?"
When I click yes, the "not responding" suffix appears and I have to force close PP. The clip apparently does not have any metadata - at least none appear in the Metadata tab in PP. Perhaps this is a significant clue.
Also, we use Windows Movie Maker to capture the footage to DV avi. Low tech, I know.

More jpg file corruption

I've had another jpg file corrupted in the same manner as before and this time the file hasn't been touched recently by anything but LR. My second copy was also corrupt because I "back up" too often. Fortunately, it's easy for me to get files back from my internet backup, which is written only once. To get to my CDs or DVDs would require digging in a closet.
To me this brings a lot of issues to the fore with jpg handling, both what I do with them and what LR does with them. First, if you are going to rewrite files frequently (I only write metadata on demand, not automatically) then you have to know how to do it safely! On my side, it may be stupid to write it out -- nope, not, because I have to in order to edit in PS and retain the metadata. I have almost innumerable LR backups and the metadata is in there. I have considerable experience now in plopping in an absolute original file and LR happily applies everything to it. Hum. I'm forgetting the PS edits which would not be backed up with this plan.
The existence of 1 to 1 previews makes it very slow to SEE a problem in LR. I haven't used these files for months until the 9th when I started working on them. The first day or so it was grinding a lot, obviously making previews. So the good preview of this file had to be made on the 9th or a bit after so the file was OK at that time. In fact, everything looked fine until I decided to edit a copy of the file in PS. It stumbled and flickered the screen and then created a preview with only the top third or so of the file intact and the bottom part "faded." These appear to still be (almost) valid jpg file, but the content has been damaged.
I have used jpg files for years and I don't remember a time when I've had jpg file corruption. I may have forgotten an instance, but it doesn't come to mind. I've had 3 or 4 them now with LR.
These jpg files were created from scans and I have manipulated them to put the capture date, date digitized, and some global type information. I use exifer, a product that's been used for many years by many people (and not updated recently). If exifer is a problem, why only a handful of corruptions in thousands of files?
It's difficult to have a sensible backup plan except to keep the originals somewhere really safe. Even with metadata writing turned off by default, these files churn. I cannot keep every version of jpg files. And keeping the old files for a short period does not help because bad files don't show up in LR under many circumstances because of the preview files.
I don't know if this is relevant but I never had this happen with LR 1.0.
This is very worrisome and I'm going to get grouchy soon! You guys with RAW are really lucky that LR doesn't write to your files! I'd now love to have an option of a sidecar file which I could write to the jpg only when I'm ready to and have a way to check that the resulting file is still intact.
Of course I haven't proven there isn't an issue with my disk drive, but I've now proven it to myself that there's a very high probability that LR is corrupting jpg files when writing out metadata. I would like to hear if others using jpg files have had corruptions.

Hi, I too also have just experienced jpg corruption. It was a jpg that had been taken several years ago and had not been edited at all. The bottom left hand corner had been transposed from the right hand side. The result of this was the whole bottom 1/5 of the picture was shifted to the right. Also the color of the shifted portion was slightly different from the rest. This is the first jpg corruption in Lightroom I have seen. My backup was the same but fortunately I had a copy on DVD. I am using Windows version of Lightroom 1.2, tried 1.3 and decided to go back to 1.2
Does anyone know if this type of corruption only happens to jpg files. Would it be worthwhile marking them all read-only. I plan to check my other jpgs to see if there are any more corruptions. I mainly shoot RAW now and convert to DNG

XMP - LR2 conflict with buddy file

Im using the German Version of LR2. After updating from LR1.4 to LR2, it doesn't write metadata changes and development changes into xmp-buddy files any more. In spite of the fact that always write changes to XMP-files is activated in the catalog preferences! LR shows the message: Conflict in the buddy file (Konflikt in der Filialdatei); XMP-metadata writing not successful.
I used old and optimized catalogs from oder LR-Versions and also created completely new catalogs.
thanks for your help,
Axel

All write operation on PC installs with LR2 will not work and give you an error. Things like convert to DNG or create virtual copy or write metadate to files. This is a documented bug and according to Adobe engineers I have been in discussion with will be fixed on the next release. I am useing 1.4.1 now until the next release.
Look up old post "Unable to creat virtual copy" or somthig to that effect from about a week ago. It's all there. What can I say, they are working on it.
P.S. It is not a conversion issue. Even if you create a new catalog from scratch it still there.

Metadata Writing

Similar Messages

Maybe you are looking for