@jch2103, @Joanna, @RKyburz, @sgospodarenko
@jch2103 you and others have been concerned about the standards adopted for handling metadata in nPL5. While I am more concerned about how it seems to go about certain tasks.
The FAQ to be published should give us a clue to the way that the software engineers think but in the meantime I have been making a few tests.
So the scenarios that need to be handled are (I believe) ;
Scenario 1 - Database Only
Scenario 2 - Database & DOP
Scenario 3 - Database & DOP & Photo
Scenario 4 - Database & Photo
Scenario 5 - DOP only
Scenario 6 - DOP & Photo
Scenario 7 - Photo Only
Scenario 8 - Empty DOP & Photo
In all of the above the photo must be present but those identified as including “Photo” mean Photos with e.g. ‘Rating’ set in the photo metadata.
In only one of the above scenarios were the values in the Photo actually used, namely scenario 7 (this was written before I added Scenario 8). Unfortunately this assumes that PL4 was working in a “vacuum” or recognised any and all changes to the Photo as they occurred and noted them in the database and DOP.
Firstly I consider this model too simplistic because there is a risk that data in the Photos will be “lost” unless a forced metadata read is made (not a bad idea) but worse it seems to run contrary to the complaints that have been made about loss of ‘tags’ and ‘Rank’ (‘Ratings’) in the move from PL4 to PL5!!
According to my tests the only situation where data would be “lost” is if PL5 thought that a PL4 photo was actually to be imported, since this is devoid of any of the metadata that we are looking for, i.e. the photo is devoid of any data because of PL4 immutability so there is nothing to import into PL5.
Given that in all the scenarios I reviewed only one took anything from the photo and in all the others PL4 data was always there I fail to see what else could be going on (though that could just be me being short sighted)!!
That still doesn’t explain why it works for some users and not others. I used none of the options(Tags etc) when using PL? for my own work, so when my database went missing during the upgrade I didn’t really care but managed to salvage it anyway!
The rules do change once PL5 is working with its “own” database records and DOPs, the Photo becomes the major source of the metadata (though that depends on the Sync option and the manual reads and writes). This data will be missing if the photo is a PL4 photo and that might point to how PL5 starts “losing” data. What triggers a transition from the data being treated as old PL4 to new PL5 I am not sure, in the DOP it is clearly identifiable but in the database? My tests also indicated that the presence of the PL4 DOP is sufficient to cause the data to be taken from the DOP rather than the photo.
I haven’t tested a mix of the scenarios in one directory/sub-directory.
@sgospodarenko Unfortunately I decided to copy the tests that start with a PL4 database so that I can repeat those pertinent with a PL5 database that has already “seen” the PL4 data. Unfortunately, I accidentally killed a copy and was left with a right mess of a pair of directories. I put the data back together (or so I thought) and hung PL5 right from the start. Eventually I restarted the machine and restored the directories but now PL5 is hanging while attempting to read the directories and display the photos.
More work is needed to get things back the way that they were and avoid the following (see snapshots), a job for another day!!
