Milliseconds truncated - (solved 2890 but back in 3240)

[lintujuh]

I was debugging my DamCompare tools based on Egon's report on false positives in creation time.

Based on my test cases, my conclusion is

• milliseconds are imported into database, even though they are not visible in GUI
• if you update creation time in Daminion, the milliseconds are dropped from database, but they remain in EXIF data

I don't need the milliseconds in GUI, so the first bullet point is fine. They could still be important for sports or wildlife photographers shooting in continuous mode, so other users might want to see also them. The second bullet point is IMO breaking the key principle in Daminion that the data in database equals to data in the image.

-Juha

[Uwe]

Hi Juha,

I understand what you mean and from a IT point of view you are right and I agree.

But there is an other side in my mind: I use the milliseconds to get the right sort order of photos taken in the same second (e.g. photos of waves on the sea). If I modify the the Creation DateTime in the Properties Panel I don't want to lose the milliseconds. The reason to adjust the time stamp can e.g. be a wrong time zone setting in my camera that has to be adjusted. I can do it by the shift action or manually. If I rename now the file (YYYYMMDD_HHMMSS_MS) using the adjusted time stamp I get the MS value="000" (because of the database). A read tags from file brings back the MS and I get e.g. the original MS value="340" back to have the previous sort order.

Just some thoughts.

regards, Uwe

[lintujuh]

HI Uwe,

I fully agree with you, milliseconds shouldn't be lost.

I tested with some of the images that had lost their milliseconds and read tags from file didn't add the milliseconds into the database.

-Juha

[Daria Kotilainen]

Hi guys, I will bring my colleagues to this dialog so that they could take a look at it and fix the issue. Unfortunately, I cannot tell you when exactly it will be fixed

 

kind regards, 

daria

[clausbagge]

I wouldn’t hold my breath for this getting fixed if it’s in any way related to my post made in may 2017 - I gave up entirely;

https://forum.daminion.net/topic/3440-importing-files-missing-milliseconds/
 

[Uwe]

Hello,

an old bug is back. In some versions it worked but both with 2693 and in 2730 the information from the metadata SubSecTimeOriginal is not transferred to the variable %ms. So it is not possible to rename photos that were taken in the same second.

regards, Uwe

[Uwe]

the bug is still there in build 2734
regards, Uwe

[Oleg.Ross]

Hello Uwe.
There is no bug with the milliseconds.
At your request it was made that the creation time is taken from the file or from xmp depending on who was created last. The XMP file does not store milliseconds like the Exif file so they will always be 0. If you use only the file with the exif sub sec field, the token milliseconds work correctly.

[Uwe]

Hi Oleg. sorry, but I don't agree - it is a bug. I use xmp files since they are supported by Daminion and it works before in previous releases. Daminion has many backups of my catalogs. You can check it. The basis of the dates are the tags DateTimeOriginal and SubSecTimeOriginal. Both tags are in the Exif metadata. If Daminion now doesn't read Exif metadata but xmp then I expect the SubSecTimeOriginal tag in the xmp too.

Regards, Uwe 

 

[Uwe]

Hi, is this bug fixed in 7.7?

Regards, Uwe 

[Uwe]

Hello,

since there is no information about this yet I would like to give a few arguments for the necessity of the %ms bugfixing.
The Preferences regarding the XMP files in the settings is no longer usable for all media formats that use xmp sidecar files and require the parameter %ms. This means that you have to work without sidecar files and all adjustments of the metadata have to be done exclusively in the RAW files, which contradicts the sense of the XMP files.
All photos taken in the same second can no longer be sorted by the time they were taken. This means that photos of all fast-moving objects (e.g. sports, birds photography...) are sorted incorrectly or can no longer be imported into Daminion because the file supposedly already exists. Please do not argue with the parameter %$$$ etc. now. This may be good for photos without a compulsory sequence, but not for the applications I have described.
I therefore expect the bug to be fixed asap in next build. I currently have hundreds of photos that I cannot import into Daminion.

regards, Uwe

[DAK_vzw]

On 9/13/2022 at 1:38 PM, Uwe said:

<snip>

All photos taken in the same second can no longer be sorted by the time they were taken. This means that photos of all fast-moving objects (e.g. sports, birds photography...) are sorted incorrectly or can no longer be imported into Daminion because the file supposedly already exists. Please do not argue with the parameter %$$$ etc. new. This may be good for photos without a compulsory sequence, but not for the applications I have described.I therefore expect the bug to be fixed asap in next build. I currently have hundreds of photos that I cannot import into Daminion.

</snip>

As I have installed the latest version today (7.6.0 build 2693) I noticed this annoying problem remains unsolved. I totally agree with Uwe. In fact, I am really surprised of the Daminion reaction, as I used to be extremely happy with the provided solutions and respond time. I was in contact with the Daminion staff about this, tackling this issue already from version 4.x on. I suggested to have a secondary option to sort files by name on import, which totally eliminates the need for milliseconds, but had no return so far. Guys, this can't be that hard? PLEASE?

 

Already thanks for your time!   

[Uwe]

Hello,
the bug ist still existing in the official 7.8 build 2874.
regards, Uwe

[DAK_vzw]

Why not just have an option to sort by FILENAME on import, which will keep the correct order from the camera? Can't go wrong... & plenty of time to examine and resolve the timing problem?

 

Kind regards, Stijn.

[Uwe]

Hello,
today tested again with the build 2890 - it works!
1. Copy RAW files from CF Card to internal folder + GPX file from Garmin Oregon 600
2. GeoSetter writes GPS metadata into the RAW files AND creates the XMP sidecar with the GPS metadata
3. copy RAW and XMP files to the Import Folder - then moved by Daminion into the Upload folder
4. the Action Rename/Move (%date_%time-%ms.%ext) uses the tag SubSecTimeOriginal from the RAW file and all files are moved from the Upload folder into the final folder on the NAS
Regards, Uwe

[DAK_vzw]

@Uwe Hello Uwe,

Yes, I was already informed that a solution was coming 😉
It took a while, but finally... This issue was more complex than initially predicted.
Tested with 2890, works fine to me.

Regards, Stijn.

[Uwe]

Hello,

the bug is back - tested in 3240.
A RAW file has the tag SubSecTimeOriginal in the Exif metadata but not in the sicecar XMP file. Renaming the file "20230924_113941-98.cr2" with the pattern "%date_%time-%ms.%ext" will delete the value from SubSecTimeOriginal "20230924_113941-000.cr2" previously present in the file name.
Please correct this error, which was already fixed, as soon as possible.

regards, Uwe

Edited October 6, 2023 by Uwe