Paul Barrett Posted June 4, 2018 Report Share Posted June 4, 2018 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: 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? Quote Link to comment Share on other sites More sharing options...
fhahn Posted June 4, 2018 Report Share Posted June 4, 2018 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: 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 Quote Link to comment Share on other sites More sharing options...
Paul Barrett Posted June 4, 2018 Report Share Posted June 4, 2018 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 Quote Link to comment Share on other sites More sharing options...
Daria Kotilainen Posted June 4, 2018 Report Share Posted June 4, 2018 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 Quote Link to comment Share on other sites More sharing options...
Paul Barrett Posted June 5, 2018 Report Share Posted June 5, 2018 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 Quote Link to comment Share on other sites More sharing options...
WilfriedB Posted June 5, 2018 Report Share Posted June 5, 2018 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 with 00 seconds in the Daminion catalog and among these 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. 1 Quote Link to comment Share on other sites More sharing options...
Uwe Posted June 5, 2018 Author Report Share Posted June 5, 2018 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 ;-) Quote Link to comment Share on other sites More sharing options...
Paul Barrett Posted June 8, 2018 Report Share Posted June 8, 2018 All I can hear is the cicadas... Quote Link to comment Share on other sites More sharing options...
Daria Kotilainen Posted June 11, 2018 Report Share Posted June 11, 2018 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 Quote Link to comment Share on other sites More sharing options...
WilfriedB Posted June 11, 2018 Report Share Posted June 11, 2018 ... 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. Quote Link to comment Share on other sites More sharing options...
Paul Barrett Posted June 11, 2018 Report Share Posted June 11, 2018 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. :) Quote Link to comment Share on other sites More sharing options...
Paul Barrett Posted June 11, 2018 Report Share Posted June 11, 2018 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 Quote Link to comment Share on other sites More sharing options...
WilfriedB Posted August 9, 2018 Report Share Posted August 9, 2018 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. Quote Link to comment Share on other sites More sharing options...
Alexius Posted August 10, 2018 Report Share Posted August 10, 2018 Hello everyone. We've fixed this issue. But we need example files to check and test. Please send me files to [email protected] Thanks. Quote Link to comment Share on other sites More sharing options...
WilfriedB Posted August 10, 2018 Report Share Posted August 10, 2018 Hello everyone. We've fixed this issue. But we need example files to check and test. Please send me files to [email protected] Thanks. I quickly did send one. Let me know, if you need more. Quote Link to comment Share on other sites More sharing options...
Alexius Posted August 10, 2018 Report Share Posted August 10, 2018 I quickly did send one. Let me know, if you need more. Thanks. But I don't see any information about milliseconds. Some cameras does not support this EXIF field. Quote Link to comment Share on other sites More sharing options...
WilfriedB Posted August 10, 2018 Report Share Posted August 10, 2018 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. Quote Link to comment Share on other sites More sharing options...
Uwe Posted August 10, 2018 Author Report Share Posted August 10, 2018 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 Quote Link to comment Share on other sites More sharing options...
Uwe Posted August 10, 2018 Author Report Share Posted August 10, 2018 Hello everyone. We've fixed this issue. But we need example files to check and test. Please send me files to [email protected] Thanks. Hi Alexey, I did send some TIF files to you (FTP folder and download link). Regards, Uwe Quote Link to comment Share on other sites More sharing options...
WilfriedB Posted August 27, 2018 Report Share Posted August 27, 2018 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. Quote Link to comment Share on other sites More sharing options...
Pictor Posted February 10, 2019 Report Share Posted February 10, 2019 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 Quote Link to comment Share on other sites More sharing options...
WilfriedB Posted February 10, 2019 Report Share Posted February 10, 2019 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. Quote Link to comment Share on other sites More sharing options...
Uwe Posted February 11, 2019 Author Report Share Posted February 11, 2019 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" 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:datetimeoriginal5. This is the status now and there is no error in the EXIF metadata of DateTime Original Regards, Uwe Quote Link to comment Share on other sites More sharing options...
Uwe Posted February 11, 2019 Author Report Share Posted February 11, 2019 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 Quote Link to comment Share on other sites More sharing options...
WilfriedB Posted February 11, 2019 Report Share Posted February 11, 2019 (see the post below - I had problems editing this one) Quote Link to comment Share on other sites More sharing options...
Recommended Posts
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.