Unfortunately I have to agree with Lars…
This “feature” causes so much aggravation and wasted effort when it occurs, that whatever the logic behind the current behaviour of PL, DxO really needs to change the software to either address the “bug”. Or, if its genuinely not a bug, then they need to add UI features that allow the users some level of control over what happens when this scenario is encountered.
From PL’s perspective, it’s a “fail safe” strategy - in that, if PL detects any potential for ambiguity (2 or more versions of corrections for the same source-image) then it presents all versions as separate versions (rather than arbitrarily choosing one of them as the “right one”).
There will be a reason for PL adopting this strategy when it encounters it.
Lars; Have you carried out the test I have previously suggested ?
PS. I am trying to be helpful.
That’s a fair point - You could raise that as a request/suggestion.
John M
No response … … “You cannot help those who will not help themselves”
John
Pity, I was hoping that this would lead to a better understanding of the circumstances that trigger the creation of these extra copies, because although I understand the principle behind the concept of creating virtual copies just in case data was going to be lost, my own real world experiences don’t make sense in that context.
Is there a member of the DxO staff out there who could spare the time to fill in some of the details as to the root causes of this PhotoLab behaviour?
A few specific details relating to the explicit conditions that are required to cause this to happen are quite likely to be enough for anybody experiencing this problem to understand it enough to avoid the issue.
At the moment nobody seems to fully understand the circumstances that trigger this behaviour which is a source of frustration for those who regularly encounter this behaviour when “seemingly they should not”.
Alun
I’m also curious to the why. Special since I don’t have that problem and am synchronizing between 2 pc and a nas.
I didn’t find the word ‘project’ in this thread. It seems that projects deals with virtual copies slightly different. So are projects being used in combination with this unwanted behaviour?
George
Hi @George,
interested with projects, I found Workflow management with projects (scrolling down …)
“A photo that is assigned to several projects … If you want to apply different settings or corrections to the same image that belongs to several projects, you should make as many virtual copies of the photo as you need.”
What I understand, the projects contain sort of pointers/links to the originals.
The relevant information seems to be stored with the source folder – if as dop-file, in the database or both, I don’t know.
Wolfgang
I don’t know about projects. I never used them. I think you’re right a project is a collection of pointers/links to a diskfile/edit list.
Dop files can be seen as an array of edit lists. Every new virtual copy adds an edit list to that dop file. Deleting a virtual copy is deleting an array item, deleting the image is deleting the dop file, so including the dop file/array of edit lists.
If you want to play with this, check the file size of the dop files when adding virtual copies.
But as Alun said lets hope somebody from the staff with specific knowledge is answering.
George
Personally I don’t use projects, so they are not related to the odd occasions that I see this behavior.
With a nas involved I start wondering about the effects of time sync between the nas and the machine running PL, and whether or not PL uses the time stamps on the dop files themselves in any way. I am guessing that they don’t though as there are timestamps in the dop file… but who knows…
I’ve PL installed on 2 pc’s, local, on internal disks. I use the nas as a backup, synchronize the 2 pc’s via the nas. Never had this problem.
In preferences load and save from/in dop files are checked.
What is the difference with your set up?
George
I use PL on one PC, do most of my photo editing on the local disk, then backup the edited photos by moving them to nas. When I move them to the nas I do this from PL not from windows. For the most part I do not have any issues… but I have very occasionally had what look like “glitches” where PL threw in some extra virtual copies. This has not happened enough to cause me issues, but when it has its really difficult to clear up.
In preferences I have load and save from/in dop files checked, and for the most part I only delete the PL database every now and then when it occurs to me to “clean up”. So the issue could (I am guessing) potentially be related to dop file contents not quite aligning with the database contents.
The scenario where I have seen this issue the most, is “vaguely dodgy”, as it involves copies of raw files and their associated dop files in a new directory. However this should in theory be fine, and at least 99.99% of the time it is… however very very occasionally I get virtual copies created, but not consistently, it seems 100% random.
The “dodgy copy” scenario runs kind of like this: When PL is not running I run a program that works out the edited size of each of the raw files in a directory. It then makes a copy of the raw files and their dop files in sub-directories based on edited size. Then when I start PL up again I have copies of the edited photos in new directories, sorted by size (which allows me to easily export the images using different export settings based on edited size - yes this is excessive, and I am very unhappy that PL provides no way to do this out of the box!). Anyway, very occasionally PL creates extra virtual copies for the copies in the sub directory, but this is random and not repeatable, even with exactly the same files.
I could go into more detail, but I only have suspicions as to potential causes, so that’s probably not going to add much to the conversation
Alun
It’s hard for me to say something about your issue. Also due to the fact that in your situation it happens seldom.
I don’t understand what you’re doing. What means “When PL is not running I run a program that works out the edited size of each of the raw files in a directory”
Though I use an external program to synchronize,Syncbackfree, and you do use Pl to backup, I don’t believe the problem is there.
George
Alun - A helpful approach is to use the option to sort by “Virtual copy number” … this groups all your virtuals together - so you can more easily delete them.
That’s been my suspicion too - so I tested it out;
So, the big (rhetorical) question is; what might be causing a disconnect between the Uuid in the sidecar file versus the Uuid in the database ??? … To which I have no useful suggestions !!
John M
It means that I have written a script that reads the edited photo size from the dop files. This has nothing to do with PL other than the fact I had to write it to get round PL limitations. I only mentioned it to set the scene, and explain why I am making copies of raw files and the associated dop files. It has no direct relevance to the extra virtual copies.
Alun
Ah yes that would help somewhat, that had not occurred to me. My trouble is that I create virtual copies quite regularly, so in my case its not quite as simple as just removing the virtual copies. I have to check every single virtual copy, and only delete the ones that have identical edits, which is, to say the least a tedious and potentially error prone task. That said, having thought about it, I could probably locate the genuine duplicates programmatically using a script as well.
On a similar note, the next time this happens I think I will do a full analysis on the affected “before and after dop files”. Although I am still suspicious that this is actually a problem with the database getting out of sync with the dop files. I guess I can look at the database too, as its only an sqlite database, but as I treat the database as “disposable” I may or may not have a backup to refer to, so that is potentially more problematic.
Good test, that seems to rule out timestamps.
As you suggest the Uuid behaviour makes sense.
Indeed.
On the Uuid front I can add a little more information. I have to double check this, but from memory I was worried about duplicate Uuid’s when I copied the raw file and its dop file to a subdirectory, but it seems like PL copes with this cleanly and assigns a new Uuid to the copy in the subdirectory when I allow it to discover the new directory.
Alun
Is there a way to sort just the virtual copies out? I keep accidentally using the shortcut from Lightroom ‘alt D’ to deselect and making copies. If I don’t control Z quickly enough (before performing another click, I’m stuck with them. Help!
For Mac, the shortcut for creating a copy is Cmd-D. I thought it was Ctrl-D for Windows. Surely it’s easy enough to just delete the highest numbered virtual copy?
Hi Trish
Yes, on the Win10 version of PL you can use Sort by Virtual Copy Number option - so you can then select all the unwanted VCs as a group (Click + Shift-Click) and delete them all in one go.
John M
I have PL5 and sync between computers using Microsoft’s OneDrive. Everything seems to work fine but any edits to images/metadata on one computer seem to result in virtual copies being created on the other machines. The result is hundreds of virtual copies in multiple directories. I’ve not yet figured out any settings to help eliminate this but I’m hoping there is some method out there to solve this.
There is no setting as such. If you don’t use Projects or persistent History, then simply delete the database after each computer has closed PL.
Either that or, with Windows, I believe you can move the database to a common directory on a shared drive, but don’t quote me on that as I use Macs.