Jump to content

Milliseconds truncated - (solved 2890 but back in 3240)


lintujuh

Recommended Posts

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

Link to comment
Share on other sites

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

Link to comment
Share on other sites

  • 4 months later...
  • 2 years later...

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

Link to comment
Share on other sites

  • 5 weeks later...
  • 1 month later...

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.

Link to comment
Share on other sites

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 

 

Link to comment
Share on other sites

  • 2 weeks later...
  • 2 weeks later...

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

Link to comment
Share on other sites

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!   

Link to comment
Share on other sites

  • 4 weeks later...

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

Link to comment
Share on other sites

  • Uwe changed the title to Milliseconds truncated - (solved 2890)
  • 11 months later...

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 by Uwe
Link to comment
Share on other sites

  • Uwe changed the title to Milliseconds truncated - (solved 2890 but back in 3240)

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...