Jump to content

1212 - 1819 - DateTime Original seconds = 00 deleted


Recommended Posts

I thought, erroneously, that this issue was only related to my scanned images, where I routinely edit Date/Time original to make it the date the original was taken.

 

But to my horror, I have just discovered a number of digitally shot photos, on which I have never had reason to edit the Date/Time Original because it didn't need it, also have the problem:

 

post-3427-0-27035900-1528139498_thumb.png

 

This makes the need for a utility to find and correct dates that are incomplete, all the more urgent, because without examining the entire library I have no way of knowing how many images may be affected

 

HELP!

 

PS. Daria, did the guys agree to add it to 5.9, and when can we expect to see that please? Roughly? Just a WAG?

 

 

Link to post
Share on other sites
  • Replies 71
  • Created
  • Last Reply

Top Posters In This Topic

Top Posters In This Topic

Popular Posts

+1   When can we expect this to be fixed please?   It's a tiny bug, but creates problems orders of magnitude greater. Because of this problem, Synology Moments cannot sort the files correctly, an

I agree with Paul. We have three different issues: Not only to prevent Daminion from removing the time stamp, but also to discover potential victims, i.e. those which have a Creation Datetime w

Posted Images

I thought, erroneously, that this issue was only related to my scanned images, where I routinely edit Date/Time original to make it the date the original was taken.

 

But to my horror, I have just discovered a number of digitally shot photos, on which I have never had reason to edit the Date/Time Original because it didn't need it, also have the problem:

 

post-3427-0-27035900-1528139498_thumb.png

 

This makes the need for a utility to find and correct dates that are incomplete, all the more urgent, because without examining the entire library I have no way of knowing how many images may be affected

 

HELP!

 

PS. Daria, did the guys agree to add it to 5.9, and when can we expect to see that please? Roughly? Just a WAG?

 

Like you just found out, it affects any file that has a timestamp that ends in ".00". You cn change it back but once you make a change to the files metadata, it gets truncated again.

 

Probably the easiest way to fix the files is with exiftool. You should be able to find the files with the missing ".00", just be careful, exiftool can make changes to a large amount of files in a hurry.

 

Frank Hahn

Link to post
Share on other sites

Like you just found out, it affects any file that has a timestamp that ends in ".00". You cn change it back but once you make a change to the files metadata, it gets truncated again.

 

Probably the easiest way to fix the files is with exiftool. You should be able to find the files with the missing ".00", just be careful, exiftool can make changes to a large amount of files in a hurry.

 

Frank Hahn

 

Thanks Frank.

 

Yes, I'm acquainted with the the dark magic of ExifTool. The thing is, each of will have to spend a lot of time writing, testing and running the exiftool commands to rectify this.

 

My view is that since Daminon has corrupted our data, it is reasonable to expect Daminion to provide a utility to fix it.

 

Paul

 

 

Link to post
Share on other sites

Hello guys,

 

Unfortunately, I'm coming with bad news for you. The guys told me that this issue will not be fixed in the upcoming build because they are focused on other tasks now prior to handling milliseconds in metadata. We apologize for taking so long to fix this issue and encourage you to change :00 to :01 with Daminion or with Exiftool. Sorry again for these inconveniences, but we cannot promise you anything that will not be fixed in the nearest future - that would be very unfair and disrepectful to you.

 

Kind regards,

Daria

Link to post
Share on other sites

Daria

 

Thanks for the update.

 

It's not your fault so we won't shoot the messenger, but this is wrong on so many levels.

 

1. It's a bug

2. It has corrupted our data and continues to do so

3. So it's not just an irritating display issue, it's a data destructive bug

 

And the guys don't think that merits any kind of priority?

 

Daminion's core proposition is the ability to manage the metadata across massive libraries. This bug seems to be a complete repudiation of that proposition.

 

Really, really, not good.

 

Please, at the very least, give us the syntax for an exiftool command to scan all folders and:

 

1. Where the time ends 00 make it 01

2. Where the final one or two segments of the time are missing, (I have both) replace them with 01 or 00:01 as appropriate.

 

You guys created this problem. It's not unreasonable to ask you to fix it

 

Regards

 

 

Paul

Link to post
Share on other sites

I agree with Paul. We have three different issues: Not only to

  1. prevent Daminion from removing the time stamp, but also to
  2. discover potential victims, i.e. those which have a Creation Datetime with 00 seconds in the Daminion catalog and among these
  3. find those whose time stamp is missing in the metadata

1. Where the time ends 00 make it 01
This should be done against the Daminion catalog, instead of using the ExifTool. To discover the "potential victims" might not be that difficult by running an appropriate SQL against the catalog. Then it should be enough to set the seconds to 01 and let sync do its job. However, the question is, whether this really applies to all images which have 00 seconds. If so, it would be ~1.5% of all images which have been synced.
  • Upvote 1
Link to post
Share on other sites

Hello Daminion team,

I'm not satisfied with this answer. From my point of view it's a bug and should be fixed now. This bug leads to the situation that other programs don't work because it's a bug handling EXIF metatada and these metadata are international standards and not Daminion specific.

I don't want to enter 01 - 00 should work. AND I can accept to live sometime with a workaround. But now it seems to be time to fix it.

AND yes, there should be a tool/report/instruction delivered by Daminion to find all these corrupt metadata. Depending on the amount I can decide to fix it manually or to ask for another tool to fix it.

I don't want to have a difference between metadata in the file and the database.

The problem in this case is: In the Daminion UI everything seems to be ok but it is not.

Regards,

Uwe

PS, hope dies last ;-)

Link to post
Share on other sites

Hi guys,

 

 

On last Friday's meeting this task for re-opened and assigned to Valery, we have good chances to see it fixed soon, though the guys cannot guarantee to fix it in 5.9 because it's almost ready to be launched. Sorry for not informing you earlier, I didn't attand the meeting and got the updates only now.

 

kind regards,

Daria

Link to post
Share on other sites
... we have good chances to see it fixed soon ...

This is good news Daria! However, beside fixing the bug in Daminion, we need a tool (probably more urgently) to discover how many and which of our images are involved.

Using SQL, I find out more than 10,000 (ten thousand!) of my images have a Creation Datetime ending with 00 seconds. Doing some random verification, I found that only for some of them (not sure how many) the DateTimeOriginal tag of the metadata is truncated. It seems to me it only happens, when the Sync process writes metadata after changing any of the tags, but it does not happen, when I stop sync and use Actions -> Write Tags to File instead.

... give us the syntax for an exiftool command to scan all folders...
Paul's suggestion doesn't seem to be a reasonable approach, since ExifTool needed to open each single image file and would run several days. Nevertheless I believe such a "repair tool" could be standalone and does not necessarily need to be part of the Daminion client or server code.
Link to post
Share on other sites

This is good news Daria! However, beside fixing the bug in Daminion, we need a tool (probably more urgently) to discover how many and which of our images are involved.

Using SQL, I find out more than 10,000 (ten thousand!) of my images have a Creation Datetime ending with 00 seconds. Doing some random verification, I found that only for some of them (not sure how many) the DateTimeOriginal tag of the metadata is truncated. It seems to me it only happens, when the Sync process writes metadata after changing any of the tags, but it does not happen, when I stop sync and use Actions -> Write Tags to File instead.

Paul's suggestion doesn't seem to be a reasonable approach, since ExifTool needed to open each single image file and would run several days. Nevertheless I believe such a "repair tool" could be standalone and does not necessarily need to be part of the Daminion client or server code.

 

I'm not precious about this. Any fix is better than no fix. Hell, I'll even rescan the whole friggin' library in Daminion if I have to. :)

 

 

 

Link to post
Share on other sites

Hi guys,

 

 

On last Friday's meeting this task for re-opened and assigned to Valery, we have good chances to see it fixed soon, though the guys cannot guarantee to fix it in 5.9 because it's almost ready to be launched. Sorry for not informing you earlier, I didn't attand the meeting and got the updates only now.

 

kind regards,

Daria

 

Thanks Daria. Really looking forward to getting the issue fixed

Link to post
Share on other sites
  • 1 month later...
It seems to me that the problem occurs when Daminion writes a time/date stamp to Exif:ModifyDate. As long as Exif:ModifyDate has an entry, I can't get the final "00" to be written. I have tried using exiftool and the ExifToolGUI tool to write this field. When the Exif:ModifyDate field is emptied, I can then write the final "00" back.
The statement "when Daminion writes" is not quite precise. It does happen consistently if Daminion writes the meta data during the synchronizing process, however if you select Item->Actions->Write tags to file, the time stamp in the metadata is written correctly. The difficulty still remains to identify images with incomplete Date/Time Original. Quite disappointing, Daminion cannot provide a solution within more than three years.
Link to post
Share on other sites

Thanks. But I don't see any information about milliseconds. Some cameras does not support this EXIF field.

As far as I can tell, there was never an issue with milliseconds here (but possibly in a different thread of this forum). The issue here applies, if the time stamp ends with :00 seconds, the sync process writes an incomplete EXIF time for "Date/Time Original" which ends with a colon (:) instead of :00. Several programs, such as Facebook upload, GeoSetter and others then completely ignore the time stamp.

Link to post
Share on other sites

Thanks. But I don't see any information about milliseconds. Some cameras does not support this EXIF field.

Hi Alexey,

regarding milliseconds: This is another issue. Please check the post: https://daminion.net/user-forum/index.php?/topic/2996-import-tag-preset-using-ms-doesnt-work/

Yes, not all cameras create the EXIF metadata tag "SubSecTimeOriginal". But if existing - it should work, if not, Daminion should set "00" to the variable "%ms".

Regards, Uwe

Link to post
Share on other sites

Hello everyone. We've fixed this issue. But we need example files to check and test. Please send me files to alexey@daminion.net Thanks.

Hi Alexey,

I did send some TIF files to you (FTP folder and download link).

Regards, Uwe

Link to post
Share on other sites
  • 3 weeks later...

The problem still appears with Daminion 6.0 (1819).

Whenever the Date/Time Original ends with 00 seconds and the sync process writes the meta to the file it results in

Exif Version 0230

Date/Time Original 2018:08:22 12:06:

Create Date 2018:08:22 12:06:00

Since the seconds are missing in Date/Time Original here, several applications completely ignore the date.

Link to post
Share on other sites
  • 5 months later...

Daminion Vers. 6.0 final (1904)

Standalone Version

 

Windows 10 Home 18-09 64bit

 

 

The bug still exists.

 

 

Exif-data with SubSec:

- Tag SubSecTime........................missing

- Tag SubSecTimeOriginal...........only one digit left

- Tag SubSecTimeDigitized..........only one digit left

 

Exif-data without SubSec

- Tag DateTimeOriginal.................Sec missing

- Tag CreateDate...........................Sec missing

 

 

You received the first error message in May 2015. Now we have February 2019. Why was the error not fixed? If the bug cannot be fixed, tell your customers why it can't be fixed.

 

I will not buy maintenance until this bug is fixed. A bug that destroys data must be fixed with the highest priority. Silence is a bad sign to the customer.

 

Daminion, please wake up.

 

I have created another test series including problem SubSec.

Details you will get to your support email adress (photos and screenshot of metadata via ExifTool)

 

 

A angry customer of yours.

 

Pictor

 

 

Translated with www.DeepL.com/Translator from German to English

Link to post
Share on other sites

The issue not only applies for standalone, but also for the Server version 6.0.2 (build 1904) and can consistently and quite easily be reproduced (at least on my system), but Alexey's response six month ago(!) made clear, the developers never understood (or ignored) this problem yet.

Link to post
Share on other sites

Hello,

we should check and describe in details (with examples) the current status of this issue once more. My impression is that something has been changed, e.g. the implementation of the %ms parameter. May be some "side effects" are new or "parts of the bug" are still existing.

Example:

TIF file without any EXIF metadata created by a Canon LiDE 700F flatbed scanner and the Canon MP Navigator program. In Daminion "Synch = ON" all the time.

 

0. the file name is set to 20190209_201500.tif in the scan program

1. the destination folder of the "Save to" of the scanned TIF is the IMPORT folder defined in the Admin Panel.

2. the TIF file is moved to an UPLOAD folder (defined in the Admin Panel) automatically by Daminion. Daminion creates subfolders in the UPLOAD folder depending on the current date: YYYY/MM

3. This is the status of metadata in the UPLOAD folder "2019/02". In the Properties Panel the DateTime is the timestamp of the import date, e.g. "10. Februar 2019 10:21:17"

01_TIF_scanned_after_import.jpg

4.I set the DateTime in the Properties Panel: 09 Februar 2019 20:15:00 manually. NO other tags are entered additionally. Save the input.

If more files were imported I use a "Open with..:" action "-overwrite_original "-EXIF:datetimeoriginal

5. This is the status now and there is no error in the EXIF metadata of DateTime Original

02_TIF_scanned_after_set_Daminion_DateTime.jpg

 

Regards, Uwe

Link to post
Share on other sites

Example:

Doing the same as described in the post above BUT additionally to the changed DateTime in the Properties Panel I entered tags: Title, Description, Keywords.

NOW: the seconds "00" of the EXIF DateTimeOriginal are deleted:

Date/Time Original 2019:02:09 20:15:

Regards, Uwe

Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

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.

Loading...

×
×
  • Create New...