DPL3 introduced the distinction between virtual copies. Before DPL3, all virtual copies were equal.
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.
Mark
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.
Nick
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.
Nick
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.
Nick
@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!?
PS2:-
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!
Phew!!
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).
Regards
Bryan
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.
Nick
@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.
Regards
Bryan
