I keep seeing jumps in the interval. Where do they come from?
The EXIF ​​data only show jumps of a maximum of 10ms.

LRTimelapse reads the timestamps from exif and calculates the differences which it displays as intervals.
Usually, deviations as you are seeing them are pretty normal, it could be the camera or intervalometer that doesn't trigger totally accurately. This will not be visible at all in the results, you can ignore it.

LRTimelapse reads the timestamps from exif and calculates the differences which it displays as intervals.

I did the same and read the times with the EXIFTOOL. If I do that, I only get a maximum deviation of 10ms.

So the problem is not with the timer but with reading or calculating the interval.
I see the deviations with an external timer and also with my CHDK timer. The CHDK timer has deviations of less than 1ms.

This times comes from the EXIF. There are no differences from 300ms. Only 10ms
12:41:07.37
12:41:13.36
12:41:19.36
12:41:25.35
12:41:31.35
12:41:37.34
12:41:43.34
12:41:49.33
12:41:55.33
12:42:01.32

Which exif field are you reading? LRTimelapse uses "SubSecDateTimeOriginal" if available.
Usually it comes in format:
2021:11:29 19:13:50.05+01:00

Could you please send me the exact content of that field in your files?
Best would be if you could put together a short sample sequence with like 5 files where you think the interval display is wrong and send them to me then I'll double check.
Please send via wetransfer or https://fromsmash.com/ to support(at)lrtimelapse.com

Which exif field are you reading? LRTimelapse uses "SubSecDateTimeOriginal" if available.

I extract all EXIF data with “exiftool -a -u -g1” into a file and take “Date/Time Original”.

Best would be if you could put together a short sample sequence with like 5 files where you think the interval display is wrong and send them to me then I'll double check.

I reduced now to 8 files with the following information

IMG_8583 Date/Time Original : 2022:04:07 12:42:07.32+01:00
IMG_8584 Date/Time Original : 2022:04:07 12:42:13.31+01:00
IMG_8585 Date/Time Original : 2022:04:07 12:42:19.31+01:00
IMG_8586 Date/Time Original : 2022:04:07 12:42:25.3+01:00
IMG_8587 Date/Time Original : 2022:04:07 12:42:31.3+01:00
IMG_8588 Date/Time Original : 2022:04:07 12:42:37.29+01:00
IMG_8589 Date/Time Original : 2022:04:07 12:42:43.29+01:00
IMG_8590 Date/Time Original : 2022:04:07 12:42:49.28+01:00

It looks to me as if the error always occurs when the seconds only have one decimal place, e.g. 12:42:25.3+01:00

Do you still want the 8 DNG's?

No, that might be the reason.
Why the heck would sony write only one digit decimal places??!!

This post was last modified: 2022-04-22, 16:51 by Gunther.

Sorry, could you never the less send me the images, otherwise I can't test when I'm fixing it.

Why the heck would sony write only one digit decimal places??!!

It’s a Canon and not a Sony

But it looks like that is the Adobe DNG Converter (or EXIFTOOL).

The CR3 includes the 0
Date/Time Original : 2022:04:07 12:42:25.30+01:00

Sorry, could you never the less send me the images, otherwise I can't test when I'm fixing it.

Done…

This post was last modified: 2022-04-22, 19:25 by Gunther.

It’s a Canon and not a Sony ;-)

Yeah... right... ;-) Still strange, seems to happen with CR3 files only...

Thanks for sending those files over. This issue will be fixed in 6.0.4. Thanks again for finding and reporting.

Drop me an email if you want a beta to test it. Let me know if you are on windows or mac.