Jump to content
Uwe

1212 - 1819 - DateTime Original seconds = 00 deleted

Recommended Posts

Thanks for the detailed info and my apologies for the delays with resolving this issue.

 

My developer colleagues can't reproduce this issue or maybe they don't completely understand the problem.

 

So I need to consolidate all the information that is required to reproduce and explain them this bug.

 

We will investigate this problem during a short period of time.

Share this post


Link to post
Share on other sites

I already described it earlier above. The problem is not caused by the import, but rather by the Sync process, after any of the tags had been changed within the Daminion catalog.

Whenever the "Creation Datetime" in the Daminion ends with 00 seconds and the sync process writes the meta data to the file, it results in a truncated "Date/Time Original". For this example, I just removed a Keyword:

File Name : 190207_0622_WBL_A77.JPG

Directory : D:/My Photos/2019/02/07

Date/Time Original : 2019:02:07 14:24:

Date/Time Created : 2019:02:07 14:24:00+01:00

File Modification Date/Time : 2019:02:11 13:39:40+01:00

Image Count : 41985

Modify Date : 2019:02:11 13:39:40

 

It does not happen, if you perform an "Item>Actions>Write Tags to file". In fact the Write Tags to file is a possibility to fix the situation, if you know which of your images had been corrupted.

 

You can practically reproduce with any JPG, even by changing the time stamp to 00 seconds and subsequently change any tag while sync is activated. After performing an "Write Tags to file" the result was:

File Name : 190207_0622_WBL_A77.JPGDirectory : D:/My Photos/2019/02/07Date/Time Original : 2019:02:07 14:24:00Date/Time Created : 2019:02:07 14:24:00+01:00File Modification Date/Time : 2019:02:11 14:01:05+01:00Image Count : 41985Modify Date : 2019:02:11 14:01:04

To continue the test, I performed another change. This time indirectly, i.e. I did not change a tag for this particular image, but I renamed a part of the place tag (location). This would cause the metadata of multiple images be written to the file and after the synchronization processed finished (watch the number on the lower left of the screen), verifying with ExifTool yields this:

File Name : 190207_0622_WBL_A77.JPG

Directory : D:/My Photos/2019/02/07

Date/Time Original : 2019:02:07 14:24:

Date/Time Created : 2019:02:07 14:24:00+01:00

File Modification Date/Time : 2019:02:11 14:31:47+01:00

Image Count : 41985

Modify Date : 2019:02:11 14:31:47

-- press RETURN --

 

Share this post


Link to post
Share on other sites

Hello Murat,

you got a video by Skype that shows the process and the difference between two files depending on the entered tags in the Properties Panel.

Made with build 1904.

regards, Uwe

Share this post


Link to post
Share on other sites

In Build 1924, I cannot reproduce this problem anymore.  I tested with several JPG images using the desktop client and home server. 👍

I only noticed this yesterday and shall continue to watch this issue to let you know, if I find another case of corrupted times tamps.

Share this post


Link to post
Share on other sites

Is this the end of a long journey? I made some tests with TIF files and: IT WORKS!!!

I'll continue the tests and hope you don't get any bad news regarding this topic and we can close this discussion.

regards, Uwe

Share this post


Link to post
Share on other sites
16 minutes ago, Uwe said:

Is this the end of a long jorney?

Hopefully! Not sure though, whether we know all conditions being able to cause a corrupted time stamp.

Share this post


Link to post
Share on other sites

Hello,

now it's time to correct files with the wrong tag.

I asked in the ExifTool forum for help and got this very simple solution to write back the tag. Automatically the missing value is set to "00".

exiftool "-DateTimeOriginal<DateTimeOriginal" FILESorDIRS

http://u88.n24.queensu.ca/exiftool/forum/index.php/topic,10046.0.html

Regards, Uwe

Share this post


Link to post
Share on other sites

Thanks Uwe! Apparently exiftool inspects and changes if necessary all files in a folder. How many files can it handle in an hour?

Alternatively, if you know which images are involved, performing an Item->Actions->Write Tags to File also fixes it.  But I hesitated to do so for all my images. So I ended up using an SQL select statement to find out, which Creation Datetime ends with 00, then call exiftool and examine DateTimeOriginal. After pinpointing the "infected" images, I used Item->Actions->Write to fix them.

Share this post


Link to post
Share on other sites

Hi Wilfried,

this was the way I also wanted to go but it's more effort for me. I have this problem with scanned TIF files having the file name "YYYYMMDD_HHMM00.tif" I set the Vendor and Camera Tag by the "Open with" action when I import scanned TIF file to Daminion. For me now it's okay to search/select all ( TIF files AND Camera tag ) items in Daminion (maybe year by year) and correct them by an "Open with" action.

Yes it's more time consuming but it can't go wrong.

Regards, Uwe

Share this post


Link to post
Share on other sites

Hello, Uwe and Wilfried,
thank you for pointing out that it seems that this serious bug has finally been fixed. 😉


But .....

@Daminion

where can I download Build 1924 Standalone?

I didn't find any hints or links!
Is there a change log for 1924?
What has been fixed?

Pictor

 

Share this post


Link to post
Share on other sites
9 hours ago, Pictor said:

where can I download Build 1924 Standalone?

Sorry Pictor, I forgot to mention that part: Daria posted the link to the server version in a different context. I don't know, why it was not published otherwise. So very likely, it was not completely tested yet and they didn't post the install package for the client yet. (The client was only installed after installing the server and connecting to it 😢)

 

Share this post


Link to post
Share on other sites

Hi Wilfried,

thanks for your info. I found this link before but the link is dead. I do need the  STANDALONE  version.

Pictor

 

 

Dead Link.jpg

Share this post


Link to post
Share on other sites
On 4/15/2019 at 9:11 AM, Pictor said:

 I found this link before but the link is dead. I do need the  STANDALONE  version.

Pictor, in case you did not receive a notification, have look here:

 

Share this post


Link to post
Share on other sites

Hello Uwe and Wilifried, thanks for your information and help.

---------


I don't have much time at the moment and so I just came for testing. So I tested the build 1933 (Standalone) directly. But not very detailed.

The following statements:
- The "seconds" are no longer destroyed
- The Exif data of all photos with SubSec no longer have a "SubSec Section" after entering a keyword in DAMINION. Irrespective of the seconds. So also photos with the time e.g. 14:22:17.

@Daminion:    From my point of view the problem is not solved yet.

Pictor


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

Share this post


Link to post
Share on other sites

Hi Pictor,

do you have an example? I changed a TIF file (wrong DateTimeOriginal - missing seconds).

1. exported all metadata by ExifToolGUI e.g. as TXT file

2. set seconds = 00 in Daminion and assigned a new keyword tag-> save

3. removed the just assigned keyword tag -> save

4. exported all metadata like in point 1

5. Compare the content of the exported metadata files by Total Commander (vergleiche Inhalt Dateien): no differences except the DateTimeOriginal (the 00 seconds) and the Windows system file data.

regards, Uwe

Share this post


Link to post
Share on other sites
6 hours ago, Pictor said:

- The Exif data of all photos with SubSec no longer have a "SubSec Section" after entering a keyword in DAMINION. Irrespective of the seconds. So also photos with the time e.g. 14:22:17.

@Daminion:    From my point of view the problem is not solved yet.

Pictor, it seems to me, you mention two different problems. The on discussed in this thread "DateTime Original seconds = 00 deleted"  seems to be solved - at least according to our experiences so far, whereas you second test refers to another problem "missing milliseconds":

 

Share this post


Link to post
Share on other sites

Hello,

miliseconds tag is working. If the tag "Sub Sec Time Original" exists Daminions takes it e.g. to rename the file (%date_%time-%ms.%ext). If not the value 000 is used.

regards, Uwe

Share this post


Link to post
Share on other sites

Hello, Uwe and Wilfried (and of course DAMINION),


I tested with jpg files in build 1933  Standalone.

 

If the second is zero and there is no SubSec, now everything is ok with seconds. But the field UserComment is missing.

If the exif data contains SubSec (no matter if second is 00 or unequal 00), these (and also the UserComment field) have disappeared after entering a keyword. This is a consequence of the last changes by Daminion, because before the SubSec specification was "only" corrupted.  


Therefore this is still the same problem for me.


Below is the ExifToolGUI documentation before and after inserting a keyword into DAMINION for a jpg-file with SubSec.

 

Pictor

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

 

A_Vor Änderung_DSC_1775_30.jpg

B_Nach  Änderung_DSC_1775_30.jpg

Share this post


Link to post
Share on other sites

The fact that the comment is not saved to the metadata is a different issue. Uwe and I found out, it only happens for standalone and Home Server, but seems to work fine with team server. I reported it in the forum and via a message from the client, but did not get any response from the Daminion team yet.

 

Share this post


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...