Unwanted virtual copies

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;

  • I opened PLv4 in a folder of 20 “new” images (that PL had not encountered before) - - and I forced creation of sidecar/.dop file for one of the images. Then I closed PL.
  • With PL NOT running - I changed the date-time on the sidecar/.dop file
    – I restarted PL … No reaction (no new VCs created).
  • With PL NOT running - I changed the “Date” value within the sidecar/.dop file
    – I restarted PL … No reaction (no new VCs created).
  • With PL NOT running - I changed the Uuid (Universally unique id) within the sidecar/.dop file
    – I restarted PL … No surprise; PL created a VC

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.

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;

  • Every time any of your 3 instances of PL encounters an image that it has not see before, it makes an entry for it in its local database.
  • When you edit any image with PL the details of the corrections you applied are entered into the database AND (according to your Preference settings) are also written to a sidecar/.dop file.
  • Entries in the database and in the sidecar/.dop file are “stamped” with a common unique identifier.
  • When PL encounters, for a specific image, an entry in its database and a sidecar/.dop file with different IDs it has no way of knowing which is the “correct” version - - so, it plays-safe by ensuring that both/all versions are stored in the sidecar/.dop file … Which is why you’re seeing multiple VCs.
  • They’re “unwanted” from your perspective, but they’re “necessary” from PL’s !

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.

  • I delete the database before each PL session (via a wrapper that then goes on to invoke PL) - and I rely completely/only on the sidecar/.dop files to retain all my correction settings.

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.

imageimage

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?