Remove Distinction Between Master and Copies in VC

DPL3 introduced the distinction between virtual copies. Before DPL3, all virtual copies were equal.

  • Please bring back this egalitarian schema or add a possibility to make any VC the master

The current master/copy implementation seems to create handling issues.

I agree, Unless The master is necessary for some future planned enhancement, I would prefer if we went back to the way things used to be.


1 Like

I voted for it.
Yet it seems some users requested this feature so why not make it optional? It’s just a parameter in the .dop sidecar file. The program would behave accordingly.

Maybe that’s the reason it’s currently still useless.

Not that I can see this on Mac. There is NO parameter in the DOP file and entries were not sorted when I tested.

If you find the parameter in the DOP sidecar, let me know, after all, I only checked on Mac. If you like, you can attach a sidecar from Win and I’ll check it.

I didn’t find it either. Yet it must be somewhere.

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.

The original scenario:-

In the database:-

but one entry is missing because I didn’t scroll down far enough!

But on re-opening PL6.0.1 I got

and that occurred again until I realised that the data was being taken from the DOP!

Last attempt:-

The database started as

I deleted all entries except one with ‘Id’ = 69 giving

and, after removing the DOP (by name change) we finally have all VCs gone and VC[1] effectively now the [M]aster!


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.

@platypus Agreed this is the first post I have made in this topic!

I failed to reference Bug in the "Remove" of virtual copies created by @saint-112 not to be ungentlemanly but because this topic was created by you and sparked by those discussions and first referenced by you here Bug in the "Remove" of virtual copies - #57 by platypus so I felt that is was unnecessary to reference it here but now I have!

That is entirely up to you!

My post was not intended to provide a DIY solution but rather to address the issue that I had addressed before

in post Bug in the "Remove" of virtual copies - #11 by BHAYT about how VCs were numbered pre DxPL 3 and from DxPL 3 onwards and the answer is they are not explicitly numbered at all, it is all about position in the database and in the DOP (at least on Win10).



You must be right. Therefore it must be because there are in the .dop file several edits description that there are a Master and VCs. The first is the Master and the following are the copies.

@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.