Exif timestamp, file date and catalog mismatch

[CameronD]

This is either one or two related bugs, present in MP v0.72 as well as 0.75 beta (June 11 2015).
To reproduce:

• Set options so that file modification date is always updated if file is modified. (i.e. Settings->general->file operations: "Keep original date/time" is unticked for all operations
• Set to the browser panel, with the file listing in "details" mode.
• Enable columns "EXIF Date" and "Modified date", and drag them into view if they are not visible
• Select one image and choose menu "tools->change timestamp". In my case the camera (an old phone) always recorded the date taken as UTC, so I used EXIF:data taken, add 10 hours and change "EXIF:date taken" and "date digitized". For testing you can use 1 hour, and change only "EXIF:date taken".
• The results are the same whether single or multiple files are chosen.

Results:

• The Exif timestamps are updated in the image file as expected
• The "file modified" date is not changed - bug 1
• The catalog is not updated to reflect the changed Exif date - bug 2. This is apparent by the "details" listing still showing the old "Exif date taken", but the metadata tabs show the new value.
• Because the file modified date has been set back to the original date, xnview does not automatically update the catalog the next time we return to this directory, and only a forced "edit->update catalog from files" will fix it.

[xnview]

do you have always this problem with lastest version?

[CameronD]

do you have always this problem with lastest version?

Not always, but sometimes. I have just tried to recreate it, and I cannot identify the conditions under which the problem occurs or not.

Stage 1:

• I copied a single jpeg into a new folder.
• increment the Exif:date-taken by 1 hour.
• The EXIF tab goes blank.
• The Exiftool tab shows that the Exif:date/time original has been correctly updated, but the "details" pane still shows the old Exif Date.
• The EXIF tab still shows blank.
• If I browse away to another folder and back, or even just open and immediately close the settings window then the Exif Date in the details pane is corrected and the EXIF tab fills again.

Stage 2:

• make 3 copies of the same jpeg into a new folder.
• pick one file and increment the Exif:date-taken by 1 hour.
• The EXIF tab goes blank.
• The Exiftool tab shows that the Exif:date/time original has been correctly updated,
• For 2 out of the 3 images the "details" pane is updated with the new Exif Date.
• The 3rd file is not updated in the details pane, even if I browse away to another folder and back.

Update:
I copied the recalcitrant file into another folder by itself, and it first got the correct data in the details pane, as XnViewMP saw it as a new file.
But then, after incrementing the date, the DB and file contents remained out of sync.
I did exiftool text dumps of the single files and compared them: only File name, File creation date File Modify date and exif:date taken are different. These differences are all as expected.

[CameronD]

Another test - 3 files in the same folder.
select all files, increment Exif:Date taken by 30 minutes, write-all, cancel.

This time,

• the EXIF tab results are displayed properly (after selecting any one file)
• The exif:date taken details have been updated as expected (using previous exif data in file, not the DB)
• The details pane does not update for any of the files.
• exit folder and return: details pane still shows wrong exif date for all files.

Note: in all this I am assuming that the details pane is getting Exif:Date taken from the DB. I cannot test this with sqlite browser, as I assume the date is buried in the opaque meta data blob.

If I select all files, but apply the increment operation one image at a time: "write" then ">" then "write" then ">" then "write" . it gives the same result as write-all.

[CameronD]

I might just be getting somewhere.
I have tried many combinations of the image that worked and one that did not. I tried changing names and numbers of files in the folder.
Nothing was consistent - sometimes it would update properly, most often not. A batch update would always fail.

I noticed that all images reported an exiftool warning: "[minor] Fixed incorrect URI for xmlns:MicrosoftPhoto"
I used the command

Code: Select all

exiftool   -XMP-microsoft:RatingPercent=   test-image.jpg

to rewrite the XMP block and remove the warning.

Then, the increment exif:date tests worked properly for every single combination that I tried, even doing 3 at once.

I then used XnViewMP to change the rating to 3 and the warning returned. This implies XnViewMP is writing invalid XMP content.

[CameronD]

That was short-lived. Back to mostly failing - even the files that worked well for a little while.
I am back to having no idea what the factor is that makes it work occasionally.

I even deleted the DB twice.

I have attached the sample images that I have been testing with.

this file triggers a "[minor] Fixed incorrect URI for xmlns:MicrosoftPhoto" warning in exiftool

xMPt_has_warning.JPG (43.54 KiB) Viewed 3307 times

this file is clean according to exiftool

xMPt_1-no-warning.JPG (43.42 KiB) Viewed 3307 times

[CameronD]

I have just tried out V0.85 beta 1 - (10 Mar 2017)
The main bug seems to be fixed - I can no longer reproduce it. The updated Exif:Date Taken always now matches between the DB and the file itself.

The other bugs are still present:

• When selecting and changing date on a single file, the EXIF tab remains blank until a different file is selected.
• The File:modified Date does not get updated.

I noticed another related bug - it is also present in 0.84, but I had never noticed it - probably due to a slightly different layout:

• Browser set to details - use a wide pane to show lots of info (or squeeze the column widths)
• In a multi-file selection, change any one of a single file's Exif's date
• Result: As soon as "Write" is pressed, much of the metadata is deleted from the display for that file.
  • blanked are: (for example) Caption, shutterspeed, aperture, print size, properties
  • retained are: filename, colour label, rating, File:created date (looks like anything not in the metadata blob)
  • However, the metadata that has changed is not changed - nor is it blanked.
• This applies to the display only - the content is redrawn when the edit time window is closed.
• The bug also happens if you have browser mode: thumbnails with (suitable) labels.

[helmut]

I have just tried out V0.85 beta 1 - (10 Mar 2017)
The main bug seems to be fixed - I can no longer reproduce it. The updated Exif:Date Taken always now matches between the DB and the file itself.

Good to read.

Fixed in next test version

The other bugs are still present:

• When selecting and changing date on a single file, the EXIF tab remains blank until a different file is selected.

I've just created a seperate bug report for easier handling, see http://newsgroup.xnview.com/viewtopic.php?t=35093

[*]The File:modified Date does not get updated.[/list]

This bug is handled in your topic 0.75: File date not modified when changing exif date.

I noticed another related bug - it is also present in 0.84, but I had never noticed it - probably due to a slightly different layout:

• Browser set to details - use a wide pane to show lots of info (or squeeze the column widths)
• In a multi-file selection, change any one of a single file's Exif's date
• Result: As soon as "Write" is pressed, much of the metadata is deleted from the display for that file.
  • blanked are: (for example) Caption, shutterspeed, aperture, print size, properties
  • retained are: filename, colour label, rating, File:created date (looks like anything not in the metadata blob)
  • However, the metadata that has changed is not changed - nor is it blanked.
• This applies to the display only - the content is redrawn when the edit time window is closed.
• The bug also happens if you have browser mode: thumbnails with (suitable) labels.

Right, a related bug. Please create a separate bug report for easier handling.

[CameronD]

...Right, a related bug. Please create a separate bug report for easier handling.

Done: http://newsgroup.xnview.com/viewtopic.php?p=139845

[xnview]

Issue 686 is fixed in next version.

[xnview]

This problem is supposed to be fixed in XnView MP 0.85 beta 1. Please check and confirm the bug fix here.

[CameronD]

Hmm, it might be fixed, but not optimally.

64-bit version, Windows 7.

Increment Exif:date taken (or any time) and the program spins its wheels for a while, becomes unresponsive, and in the meantime the task manager shows that the program has read and written approximately 700MB. This is roughly double the size of my database on disc.

I did not notice it in V0.84, but now that I recheck, it is present in the previous beta version of 10-Mar-17

This seems to happen independent of which data I change and whether I have "Create Exif if needed" ticked.

Update: this is 700MB per file. Selecting 3 files, write-all and the I/O is over 2GB each read and write.

[xnview]

Update: this is 700MB per file. Selecting 3 files, write-all and the I/O is over 2GB each read and write.

right

[xnview]

This problem is supposed to be fixed in XnView MP 0.85 beta 2. Please check and confirm the bug fix here.

[CameronD]

I can no longer reproduce the bug. Changing the times seems reliable and it does not entail vast I/O processing.