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.
You can put the database on a shared drive but only ONE copy of PL can/should open the database at a time. The database is a single user database and does not support multiple user/program access.
Eeek! That’s a serious problem making something possible but dangerous. Mind you, personally, I would much prefer not having to use the database for image editing at all - all that duplication of DOP file data, etc.
I tried that in testing but it just created a new database for each computer (named for the computer even) in the shared location even though I ensured the databases were closed and synched before opening it on the next computer.
It would be helpful if there was a prioritize sidecar setting and so it always went with that instead of creating virtual copies every single time. I’m still testing more scenarios see if I can find a combination that works but it does seem strange to have a 3 computer license and then be in a situation where it can handle multiple computers well at all.
Just to clarify: the database uses is SQLite which is used by Lightroom, Photo Mechanic Plus, ACDSee and many others. This is an open source, embedded database and has become the standard for many applications including in the iPhone and Android. The database can be setup as a multiuser database but I have yet to see any app do that which includes photo software.
So, to confirm my understanding: You have one set of image files (plus their related sidecar/.dop files) shared by all 3 PCs … Right ?
I gather you’re not following Joanna’s suggestion; so, you have a unique instance of the PL database on each PC.
What’s occurring is this;
The simplest way around this would be to delete the database (as suggested by Joanna) - - which is the way that I operate … but this will work for you ONLY if you have no interest in Keywords and you don’t use Projects, as data related to these features is NOT stored in sidecar/.dop files.
Hope that helps … John M
I’ve not tried this myself, but I’m surprised it did not work - - assuming you’re NOT running PL on more that one PC at the same time (due to single-user database limitations noted by Keith).
You would need to create the database using ONE of your instances of PL - and then update the Preference settings on the other PCs to refer to the same/common database location.
Is this what you tried ?
I would be perfectly happy with this as a solution if it is possible. I do want to use keywords so it seems I need to keep using a database. Yes this is exactly what I tried. I pointed all 3 computers to a single location and then deleted the databases. I started PL on one machine and it created a database named database. I exited and let that fully sync to other computers. I then opened one of my other computers and it created a new database called database-Computer Name. It seems there is an identifier if some kind in databases linking them to the computer that created them making this a non-workable solution. For now it seems I just may have to delete the virtual copies every session until there is either a better solution or I look elsewhere for my photo needs.
Concurrent access to the database would be the safest way to mess up Photolab.
I strongly advise against implementing it or even to ask for it.
Didn’t try for a long time, but how would you quickly delete virtual copies in hundreds of images?
Someone had suggested sorting by virtual number and that works like a charm as it puts them all together so they can be removed in one action. Now if only I could view all subfolders together it would be even easier!
I didn’t know it did this - but it makes sense; I guess it’s in-built protection from potential for a user to attempt opening multiple concurrent instances of PL on the one database.
That would be a great pity (if you were forced elsewhere) … but I cannot think of any other workaround !
Whilst not exactly “quick” ! … a convenient way to make this tedious process a little easier is to use the Sort option - by Virtual Copy Number … which groups all VCs together so you can [Click + Shift-Click] to delete them all in one go.
John
Yes, it would be sad. I chose to get PL5 because I was so impressed with how it rendered my raw images from my Sony RX100 compared to all other options I’ve seen. But I do have to weigh this against this significant usability problem and it’s certainly is a big one. Here’s hoping for an eventual real solution as my desire is to make DxO my choice going forward.
…unless you deliberately use virtual copies.
In this case you might want to cite Mark Watney (“The Martian”) if you realize that DxO added virtual copies to hundreds of images and there is no easy way to get rid of them.