XnView Software

For some unidentified reason it happens the feature doesn't work at all.

Select one or more picture, open the Change timestamp dialog, use the File modified date as source, add or substract say 1 day 1 hour and 5 minutes, select file modification date or EXIF date taken or whatever. Press "Write" or "Write all" then cancel. The dates are left unchanged.

I tried with old versions 0.39, 0.48 and 0.53 it works fine. With versions 0.56, 0.60 and 0.61 it (sometime) doesn't work.

Last Thursday evening I made some adjustments on hours, minutes to sync a set of pictures. Yesterday morning I realised that I have made some mistakes. I made some corrections and put this work on hold for some hours. When I was back I was unable to progress, the tool did not do anything.
It's not the first time this occured I thing but the first time I realise it's not me becoming mad.

DB

Do you have some files to reproduce the problem?

Hi Pierre,
It's not related to a specific file or file format (jpeg, txt, mov,...). This issue can be tested with any sample picture included in the standard Windows distribution.

When it happened on Saturday evening I tried with various collections of pictures and single files. I tried also on my netbook PC with same result. Both machines are running Win 7.
I tried again on Sunday morning after fresh reboot of the machines and as it was the same issue I decided to post this bug report.
Strange is the classic version of XnView does the job and old versions of MP does it as well.

Tonight I tried again with a fresh copy of MP v0.61 and still the same issue with my PC on Win 7. I put this version on a USB memory as well as a copy of a version 0.53, load on a virtual PC with Windows XP. I've got the results below:

Source for dates | File Creation | File Modification | EXIF taken
Version 0.53 | OK | OK | OK
Version 0.61 | Nok | Nok | Nok

For these tests I used one of the sample pictures provided with Windows.
The destination fields to change have no influence on the results. It can be File Creation, File Modification, EXIF taken, EXIF digitized, EXIF modified individually or all 5 together.

DB

Anyone else having the same experience?

I'm still using the standard XnView when I need to change dates. With the last version of MP the feature doesn't work anymore

could you post screenshot of what you do?

Here it is.
I selected a single picture from the samples provided with Windows. In the background you can see the thumbnail, with the (EXIF) Picture Taken date and the file modification date. The file properties are visible as well. I selected file modification as well as 2 EXIT date to be changed based on the file modification date as source (adding 44 days 17h and 8 minutes). After having pressed the Write button the second screenshot shows the same information under the thumbnail as well as the file properties and the EXIF tab. Nothing changed

B.Douille wrote:Anyone else having the same experience?

I am certainly having problems, but I am not sure if it is exactly the same.

V0.64, 64-bit Windows 7.

These are all scanned images, with limited or no Exif data. I use ExifToolGui to confirm whether changes have happened.
In all tests the option "Create Exif metadata if needed" is enabled.

Case 1: No Exif block in original image,
Nothing happens: The file is unchanged, the file modification/access and create dates are all unchanged.

Case 2: small Exif block in original image (created by photoshop CS). "Exif:DateTime" (file change date) is the only exif date field present.
Try to assign either of the dates that are not present (Exif:DateTimeOriginal or Exif:DateTimeDigitized) results in nothing happening.

Case 3: same file as case 2
modify the "Exif:DateTime" by itself and this succeeds, but the file modification date is all unchanged - this is another case where my setting to not "keep original date/time" is ignored. the file access and create dates are both set to now.

So the problems I am seeing are all related to MP not being able to obey the "create if needed" flag.

CameronD wrote: I am certainly having problems, but I am not sure if it is exactly the same.

could you send me files to reproduce?

two files sent.

See Issue 323 for current status and details.

This problem is supposed to be fixed in XnView MP 0.66 or later. Could you please try and confirm the bug fix, CameronD and B.Douille?

helmut wrote:This problem is supposed to be fixed in XnView MP 0.66 or later. Could you please try and confirm the bug fix

I tried the 3 cases I listed, both one file at a time, and selecting 4 at once and using "write-all".
In all situations, the exif:DateCreated was assigned correctly.

However, in no case was the file modified date updated (Windows 7 x64) xnviewMP v0.83. Oops - I suppose now I'll have to install v0.84.

I have been using this assignment of times a lot lately, but because I am also writing captions and keywords, the file mod times get updated anyway. So I have not noticed that the time adjustment by itself does not do it.

Hi Helmut,

Confirmed it works for some time now. Thank you!

@CamronD,

I have been using this assignment of times a lot lately, but because I am also writing captions and keywords, the file mod times get updated anyway. So I have not noticed that the time adjustment by itself does not do it.

Maybe one of the options "Keep original date/time" is not ticked (I think it is by default). In the parameters you can find these under General > File operations tab

@B.Douille and CameronD: Thank you both for your trying and confirmationl!

Closed

B.Douille wrote: @CamronD,

I have been using this assignment of times a lot lately, but because I am also writing captions and keywords, the file mod times get updated anyway. So I have not noticed that the time adjustment by itself does not do it.

Maybe one of the options "Keep original date/time" is not ticked (I think it is by default). In the parameters you can find these under General > File operations tab

I always have those options unticked - it's the first thing I check on a new installation.

The rest of this post has been moved back to my original post on this issue, where it probably belongs.

This brings up an interesting issue, where the software is getting somewhat contradictory instructions.

My preferences are set to not keep original date/time for Embedded metadata change. This is quite clear.

The Exif date/time values are embedded metadata and so, by my preferences, the filesystem metadata File: last modified date should be automatically updated if I change any exif values.
The conflict is that, in the dialog box where I have, for example, ticked "EXIF: Date Taken" and assigned a value, there is another checkbox labelled "File: Modified Date", which is not ticked. Unfortunately, the operation of this checkbox has two options, neither of which is correct:

1. ticked: assign the same date taken (in my current cases, early in the 20th century) to be the file modified date. This is obviously wrong.
2. unticked: when the image metadata is written and the file modified date is automatically updated by the operating system, then the program actively overrides this by reinstating the previous value

This problem comes from having File and Exif metadata in the same dialogue.

Possible options for improvement:

• split the dialog into separate windows for file and exif metadata. This will not suit anybody who wants to assign both types to one value. I never work like that, but some users might.
• Add an option, perhaps near "create exif metadata if needed" and label it "Update File modify date if exif metadata written".
  • This should by default be ticked or not according to the user preference for keep original date/time for Embedded metadata change.
  • It could be deactivated if the "File: Modified date" is checked.

Even though I wrote about this as part of the earlier bug report, is it a separate issue and you might like to move this to a separate thread as a request for enhancement.