Users deserve a better "mouse trap" for Metadata Conflict Resolution

Providing a complete Conflict Management function:-

@sgospodarenko & @alex in a previous topic I complained about PL5 ignoring changes made to metadata which could not be written back to the image because AS(OFF), i.e. in PL5.2.0.4730 Conflict Resolution only detects externally generated conflicts. I also effectively requested that the direction of the mismatch could be signalled by DxPL as it is with LR.

At the time I suggested >, < or <> to indicate where the mismatch was coming from, i.e. PL5, the image or both! In the meantime I have changed that original suggestion to incorporate the direction indicators as part of the in the ‘S’, such that the current ‘S’ icon would only be used to signal the both situation in a recent post PL5.2.0.4732 Win 10 - Issues with PL5 missing Rating changes AS(OFF).

Recent posts from DxO seem to suggest that what has currently been developed is the end of development for Conflict Resolution!

While trying to reproduce a fault I had encountered (as in the above identified post) I started thinking about the database field used to “persist” the ‘out of sync’ status (the ‘IsOutOfSync’ field in the ‘Metadatas’ structure) and decided that far from being a complicated development to extend to the full set of cases it is actually a very straightforward task, unless I have got something very wrong, so here goes!

  1. PL5 currently detects a mismatch situation when the metadata in an image changes but AS(OFF) means that the change cannot be captured and entered in PL5 so the ‘IsOutOfSync’ flag is set to ‘1’ and that controls the presence or absence of the ‘S’ icon from then on.

  2. Please extend the ‘IsOutOfSync’ situation to all cases where the data appears to have been changed but cannot be read or written to the image or the database for whatever reason, AS(OFF) being the main one but other situations may well arise with AS(ON)! Is there really any good reason to restrict the setting of the 'S’ynchronize icon to only situations detected with AS(OFF)!?

  3. Assign an ‘IsOutOfSync’ value of 1 or 2 in PL5 whenever an out of sync situation is detected,
    1 ‘IsOutOfSync’ = 1 when external metadata does not match PL5 and cannot be rectified by reading that data and adding to the database (the only situation which is currently recognised and flagged),
    2 ‘IsOutOfSync’ = 2 when the PL5 data does not match the external metadata and cannot be rectified by writing the data to the image. A new situation that would answer my “bug” report in PL5.2.0.4730 Conflict Resolution only detects externally generated conflicts

  4. Check the program ‘IsOutOfSync’ value with the database ‘IsOutOfSync’ value,
    1 If the database ‘IsOutOfSync’ value = 3 simply ignore the situation because it is already marked
    2 If the database 'IsOutOfSync’value = the ‘IsOutOfSync’ then simply ignore the “new” value because it is already marked.
    3 ELSE Simply add the current value of ‘IsOutOfSync’ to the database value of ‘IsOutOfSync’ and set the icon accordingly and set the database ‘IsOutOfSync’ to the new value, i.e. = 1 (image > PL5) , = 2 (PL5 > Image), = 3 both have been encountered!

Unless I have made a mistake it is basically as complicated as that. I have looked at different scenarios, e.g. multiple changes to image metadata while PL5 is shut down followed by restarting PL5 and immediately changing metadata in PL5 but before such data can be changed, PL5 should have detected the earlier changes to the image and marked the images with an ‘S’ before allowing the user to access the directory.

To ‘Compare’ or not to ‘Compare’:-

To avoid potential metadata loss it is imperative that PL5 detects such changes to the image metadata in all cases. My suggestions for a ‘Compare’ function, i.e. a user request to compare the metadata in PL5 and held in the image file(s) looking for any mismatch may not be as easy to do as the icon handling I have suggested above.

I do not know if PL5 currently detects potential mismatches/changes to metadata solely on the basis of timestamp comparisons and whether any actual data comparisons ever takes place in the current version of PL5. If no such code exists then there is a lot more new work involved in providing such a new ‘Compare’ facility. Nevertheless, it would help close the “window” of uncertainty that follows situations I have encountered during testing, when PL5 has either not detected the change to image metadata or has ignored any changes that might have been detected!

Identifying the different mismatch scenarios:-

While I like the idea of using the arrow head pointers on the ‘S’ icon they are a little small for tired old eyes like mine so it might be useful to change the icon colour to identify the three states of 1 (external image data ahead of database), 2 (database ahead of image data) and 3 (both situations identified!), possibly in addition to using 3 versions of the ‘S’ icon!

If scenario 3 is detected then some loss of metadata is going to occur, with the current implementation this situation and the risk will simply not be recognised and the user will not be informed. I consider that the whole point of using a computer product is to automatically detect such situations whenever possible and help the user as much as possible to make the “best” choice, even though it will be a compromise in this case!

Detecting and reporting Scenario 2 should focus the user to “flush” the changes made in PL5 to the image as soon as possible (or reverse the changes made), thereby helping to eliminate the occurrence of Scenario 3 because at that point the loss of some metadata is “inevitable”!

Handling the “Pop-Up” for resolving 'S’ynchronisation conflicts:-

Currently the pop-up when clicking on the ‘S’ icon highlights the ‘Read from Image’ option, if the above is implemented then the following should take place;

  1. For scenario 1 highlight the ‘Read from Image’ option.

  2. For scenario 2 highlight the ‘Write to Image’ option.

  3. For scenario 3 highlight neither option but when an option is selected by the user emphasise the potential loss of data in the database or in the image, depending on the user option chosen, and request confirmation before proceeding with the chosen option.