True. It’s probably baked into the application and might therefore be less easy to reverse.
It must be in the database, but I did not search thoroughly enough to discover the magic. I could see the additional copies with their respective UUIDs, but didn’t care to dig deeper.
I just checked in sidecars that are still treated with DOP 10 and found nothing there either.
Since I migrated my photo library about 2 years ago to my new M1 MacBook Air with a clean install, the new DPL version I had had no clue about any kind of edits. It found them in the sidecar files. So the parameters can’t be anywhere else. It could be hidden among the others parameters.
@platypus and @saint-112 if you had read my over long diatribe you would have seen that I concluded there is no information anywhere with regards to position, not in the database and not in the DOP.
It does not exist as an explicit field it is simply determined by the position of the image in the database, not in the Table as seems to be the case with the snapshots I produced because they show the items physically next to one another but via the index
My guess is that ‘idx_Items_SourceId’ allows duplicates and ne VCs, whenever they are added will go the vack of the entries for a given ‘SourceId’. Deleting from any point simply means the list is as it was before minus the deleted entry, and this is unchanged since before DxO 9!!
The [M]aster rule is simply one that DxO “invented” and is effectively controlled by the first item in that index! All the others can be deleted with impunity but when an attempt is made to delete that item for release DxPL 3 and beyond DxPL takes that as a signal to remove the ‘Sources’ entry as well, which would be O.K. but it also removes the image from the disk which is …!!
The coding to change this is trivial, truly trivial but wall versus head is easier than …!!!
PS:- just voted and became number 13. I am not sure I really care because I want a change that allows all the database data to go but leaves the image on disk intact, that is also trivial but has implications with respect to re-discovery.
A simple conversation initiated by @DxO_Support-Team etc. could easily determine an appropriate strategy, both an immediate one and a better longer-term one but they are way too busy read posts about the current bugs after a new release or working on getting PL7 EA ready for testing. This is never a good time to find a bug, but then when is!?
The reason there are no numbers is because every time a VC is deleted you either do nothing with the old number or have to run through all records changing the number to keep them “compacted” and with no gaps!?
@platypus and @saint-112 I finally manged to delete VCs and the [M]aster from the database directly and bring up PL6.0.1 with only one copy (now the [M]aster but previously a VC) but only once I had removed the DOP.
a) This reply of yours is the first you put in this thread.
b) If you already reported about the topic, adding a link to that post would have been gentlemanly.
c) I mostly miss your posts because they make me not see the forest for all the trees.
This feature request is for those who prefer services to DIY.
@saint-112 Yes but I seem to remember a post in your topic/thread from @platypus that seemed to indicate that not all seemed to be in order and it still doesn’t answer your original issue, sadly. I will DM you.