This post was last modified: 2014-03-18, 11:48 by Gunther.

Using LRT 3.2.1 pro version, Lightroom 5.

Following same workflow for past year but have now hit a wall.
Making assumption I am somehow making an error, but cannot find it.

In LRT…
Navigate to the folder with images.
Initialize.
Keyframe wizard.
Save

Then to Lightroom…
Import and filter for LRT keyframes
Adjust frames, copying and pasting as I go.
Grid mode, highlight all keyframes, save metadata to files.

Then to LRT…
Reload, and BAM!
Aperture, Shutter and ISO information columns stripped.
No adjustment curves.
The keyframe files (jogs) are stripped of all information and cannot be opened any longer.
All other jpgs are deleted from the hard drive.

Not a one-time occurrence. This is now always.

Ummm….help?
:-)

This post was last modified: 2014-03-18, 11:48 by Gunther.

JPGs deleted?? Newer heard of a case like that.
Please open an explorer Window with the image sequence folder.
Then perform the workflow and monitor the explorer window. Which step causes the images to get deleted?

This post was last modified: 2014-03-18, 11:49 by Gunther.

Hi,

I'm Mac based. Keeping Finder open on the master folder and watching it as I go through each step….

Open LRT 3.2.1
Navigate to the jpg folder
Highlight all and clear metadata, just for a clean slate.
Initialize
Keyframes wizard
Save

On Saving, LRT has now created a matching file for each jpg, with an identical name but now with a ~ following the name. Example 975A0029.jpg is now matched with 975A0029.jpg~ That new file cannot be opened. Assuming this is the XMP file, but it does not automatically delete.

I've never noticed this happening before, though I've never processed with a Finder window open, either. Maybe I shouldn't have, but decided to wipe it all out and restart, doing identical steps as noted above. This time, that other type of file is again created (XMP?) but is immediately automatically removed.

Open Lightroom 5
Import/Add folder with targeted jpgs
Filter for LRT keyframes
Grade keyframes
Grid view/highlight all/Save Metadata to files

Return to LRT
Reload
(now, for first time in a week, it reloads without stripping data)
Why? Same procedure I've been following for a year.
Though a crop curve has been added from first keyframe to final keyframe, and I made no crop adjustments in Lightroom.
Click OK on LRT automatically fixing this for me.

Auto-Transition
Save
On Saving, error message from LRT saying there is an error saving the XMP files for the two keyframes. All other frames successfully saved.
Click OK to exit error message.

The Finder window now shows the two keyframe files with the '~' files next to them (XMP?), but at least hasn't deleted all the original jpgs.

I've left LRT and Lightroom open at this point, waiting for any suggestions.
This sequence is not work project-critical, but I'm now leery of using LRT on shoots until I find an answer to where the bug is, in LRT or Lightroom, or more likely, where I am doing something wrong.

Thanks in advance!
Joel

This post was last modified: 2014-03-18, 11:49 by Gunther.

The ~ file is a temporary file. XMP Metadata has to be stored inside the jpgs according to Adobes definitions. So normally first the ~ file is being created, then the original file is being deleted and then the ~ file is being renamed. Normally there shouldn't go anything wrong. But the approach with XMP sidecar files next to RAW files is certainly perferrable.

Please send me the log file (info/show log) after experiencing the problems, maybe I can figure out, why the renaming/copying fails. Do you have your sequences in an unusual location? Maybe LRTimelapse does not get sufficient permissions? The files are somewhat locked?

This post was last modified: 2014-03-18, 11:50 by Gunther.

thanks for the help.

pasting the log file…

Please send the content of this log-file to support@lrtimelapse.com if you experience any problems.

[2014-03-17 09:57:51] DEBUG: Loading properties from /Users/joelschwartzberg/Library/Application Support/LRTimelapse/user.props
[2014-03-17 09:57:51] INFO: LRTimelapse 3.2.1 (2013-11-08)
[2014-03-17 09:57:51] INFO: © 2014 Gunther Wegner
[2014-03-17 09:57:51] INFO: http://lrtimelapse.com
[2014-03-17 09:57:51] INFO: Java version: 1.7.0_45 (64bit) from Oracle Corporation
[2014-03-17 09:57:51] INFO: Running on: Mac OS X locale: en_US
[2014-03-17 09:57:51] INFO: ------------------------------------
[2014-03-17 09:58:01] INFO: Licensed to: Joel Schwartzberg, joelcam, Burbank - Professional License.
[2014-03-17 09:58:12] DEBUG: Initializing directory chooser.
[2014-03-17 09:58:12] INFO: Done (dirchooser)...
[2014-03-17 09:58:14] DEBUG: Launching ExifTool: exiftool
[2014-03-17 09:58:15] DEBUG: Exif Tool available.
[2014-03-17 09:58:15] DEBUG: DNG Converter available.
[2014-03-17 09:58:15] DEBUG: MPEG Encoder available.
[2014-03-17 09:58:15] INFO: Detected Screen size: 1440 x 900
[2014-03-17 09:58:16] INFO: Newest version: 3.2.1 (2013-11-08), current Version: 3.2.1 (2013-11-08)
[2014-03-17 09:58:35] INFO: Loading directory: /Users/joelschwartzberg/Desktop/anza tent stars
[2014-03-17 09:58:37] INFO: Done loading directory.
[2014-03-17 09:58:37] DEBUG: Timestamp Data complete!
[2014-03-17 10:00:18] INFO: Done loading previews.
[2014-03-17 10:00:51] DEBUG: ExifTool output: 40 image files read
[2014-03-17 10:00:52] DEBUG: ExifTool output: 40 image files read
[2014-03-17 10:00:54] DEBUG: ExifTool output: 40 image files read
[2014-03-17 10:00:55] DEBUG: ExifTool output: 40 image files read
[2014-03-17 10:00:55] DEBUG: ExifTool output: 9 image files read
[2014-03-17 10:01:07] INFO: No Holy Grail sequence. Shot manually.
[2014-03-17 10:01:26] INFO: 169 XMP-files successfully saved.

[2014-03-17 10:01:26] DEBUG: Done saving.
[2014-03-17 10:18:44] INFO: Reloading XMP only...
[2014-03-17 10:18:44] DEBUG: Timestamp Data complete!
[2014-03-17 10:18:58] INFO: Fixed 1032 metadata properties automatically.
[2014-03-17 10:21:16] DEBUG: Fixing crops
[2014-03-17 10:21:16] DEBUG: Different Aspect ratios: 1.0 vs 1.01
[2014-03-17 10:23:13] ERROR: Couldn't write JPG/PNG/XMP. The XMP metadata of that file(s) seems to be corrupt. Please try to reset all development settings in Lightroom/ACR, and start over.
java.lang.IndexOutOfBoundsException
at java.io.ByteArrayOutputStream.write(ByteArrayOutputStream.java:138)
at org.apache.sanselan.formats.jpeg.xmp.JpegXmpRewriter.writeXmpSegment(JpegXmpRewriter.java:214)
at org.apache.sanselan.formats.jpeg.xmp.JpegXmpRewriter.updateXmpXml(JpegXmpRewriter.java:197)
at m.a.a(Unknown Source)
at lrtimelapse.k.b(Unknown Source)
at lrtimelapse.dk.doInBackground(Unknown Source)
at javax.swing.SwingWorker$1.call(SwingWorker.java:296)
at java.util.concurrent.FutureTask.run(FutureTask.java:262)
at javax.swing.SwingWorker.run(SwingWorker.java:335)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:744)
[2014-03-17 10:23:50] ERROR: Couldn't write JPG/PNG/XMP. The XMP metadata of that file(s) seems to be corrupt. Please try to reset all development settings in Lightroom/ACR, and start over.
java.lang.IndexOutOfBoundsException
at java.io.ByteArrayOutputStream.write(ByteArrayOutputStream.java:138)
at org.apache.sanselan.formats.jpeg.xmp.JpegXmpRewriter.writeXmpSegment(JpegXmpRewriter.java:214)
at org.apache.sanselan.formats.jpeg.xmp.JpegXmpRewriter.updateXmpXml(JpegXmpRewriter.java:197)
at m.a.a(Unknown Source)
at lrtimelapse.k.b(Unknown Source)
at lrtimelapse.dk.doInBackground(Unknown Source)
at javax.swing.SwingWorker$1.call(SwingWorker.java:296)
at java.util.concurrent.FutureTask.run(FutureTask.java:262)
at javax.swing.SwingWorker.run(SwingWorker.java:335)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:744)
[2014-03-17 10:23:51] DEBUG: Done saving.
[2014-03-17 10:27:15] INFO: ERROR writing: 975A0009.JPG
ERROR writing: 975A0177.JPG
167 XMP-files successfully saved.
2 XMP-files could not be saved.

Could not write the XMP-Metadata for some images. Have you initialized them properly?
(you can use "Metadata -> initialize Metadata")
Please follow the workflow described on lrtimelapse.com!

This post was last modified: 2014-03-18, 11:50 by Gunther.

The files: 975A0009.JPG and 975A0177.JPG seem to be corrupt according to the log file.
Try removing that files and start over.

This post was last modified: 2014-03-18, 11:50 by Gunther.

I saw that, and had considered doing so. But those corrupt files are suspiciously the first and last frames, the key frames. Will do and report back.

This post was last modified: 2014-03-18, 11:53 by Gunther.

okay, but if so, thy have probably been corrupted by Lightroom, because that was after writing the metadata in Lightroom, wasn't it?

LRTimelapse is definitely not deleting any images, even if they are corrupted. LRTimelapse always creates backup files (*.bak or ~) when manipulting the originals, so there is always a way back and you will never loose your originals. Those backup files will only be deleted after a successful operation.

You might send me those 2 corrupted files or the whole sequence if you feel I could reproduce the problem then.

I've pulled out the corrupted frames, which are the two keyframes, and reprocessed.

I now have two NEW corrupted frames, again the keyframes at beginning and end.

I've since processed a few other sequences, same workflow as I've always done, and those are fine. This ONE sequence seems to always corrupt the first and last frame, which are the first and last keyframes.

Additionally, when I reach the second pass in LRT and click 'auto transition,' LRT gives me an error message stating that I had incorrectly cropped in Lightroom and would fix the issue automatically. Yet I never did a crop adjustment.

I've given up on this one sequence. It is not project critical, just experimenting. My concern is if this same issue should happen on a sequence I actually DO need. Where is the problem? Is Lightroom corrupting the frames, or is it something with the interface between LRT and Lightroom?


Regarding the original issue of deleted frames, as expected it was MY error. I had imported via 'MOVE' instead of via 'ADD.'

Thanks for changing the subject of this issue, btw. I wanted to do the same, but thought I might be violating some sacrosanct forum policy. :-)

Like I already offered you, you might send me a couple of those images and I could try it by my own. Never had a case where JPGs have been corrupted before. I still don't know in which stage of the process this might happen.

But it's important for me to say that LRTimelapse has never corrupted any images and that data integrity has the highest priority by all operations LRTimelapse performs.