Hi Gunther,

In Mac ARM version 6.1 build 804, shift capture timestamps doesn't work. version 6.0.6 was OK.

After Lightroom upgraded to v11.4, LRTimelapse export from Lightroom became very slow in ARM version, but actually Lightroom itself export is faster than before. I don't know this problem comes from Lightroom or LRTimelapse.

Thank you.

Adressing your second point first: there is a bug in Lightroom 11.4, see: https://forum.lrtimelapse.com/Thread-lig...ort-plugin

Regarding the "shift capture timestamps" - what do you mean with "it doesn't work". Please be more concise. Descibe what you did, what you expected to happen and what happened. You can add screenshots here in the forum (click on Reply (not quick reply) then "post options", there you can add your screenshots. Also add the log file after the problems happened as explained in the header of the Bug Reports forum.

This post was last modified: 2022-08-17, 02:56 by VanCrab.

I traveled from time zone 0 to time zone -8, my drone automatically change time zone during a time lapse sequence shoot yesterday morning at 6:00AM. So the capture time of the first part was around 14:00 (still in time zone 0) and the rest was around 6:00 (correct time zone). I have to shift the capture time -8 hours for the first part so LRTimelapse could process correctly.

Shift capture timestamps should change the capture time in metadata of the original RAW files. I copied the first part of the sequence to a directory and shift capture timestamps. But nothing happened, the capture time was still 14:00. So I tried the old version 6.0.6, it works. All files changed to 6:00.

Picture 1: before process.
Picture 2: process.
Picture 3: after process. File time doesn't change.

I use V6.0.6 solved this problem, but I think it's a bug. I don't know if Intel version has the same bug.

Thanks for clarifying.
I have some DNG files from Drones here, where Exiftool produces an error "Error: [minor] Maker notes could not be parsed" when shifting timestamps in LRT - please check the log if you get the same error. I will add an option to ignore those errors in the future.

But for me this happens in 6.0.6 and in 6.1.0. (I didn't change anything in this regard between those versions).

Could you please try again with 6.1.0 and send me the log (do the test on a couple of images that you copy to a test folder). It would also help, if you could send me a couple of those images (5 is enough) in a zip file via https://fromsmash.com/ to support@lrtimelapse.com

I can reproduce this. With those DNG files LRTimelapse gets minor exiftool errors, which makes the process fail.
In the next update (6.1.1) LRT will ignore such minor errors. Thanks for reporting!

This has been fixed in 6.1.1.