Like Bryan (just above), I’m having difficulty in understanding the cause of your problem, Endre … The process you describe shouldn’t be creating VCs (?!)
When you say that you “drag the image to the desktop shortcut …”;
@John-M Unless the desktop has been used before for a similar process and the images have been deleted directly and not by DxPL then will be “chaff” still in the database with UUIDs which might match or not all of the time only some of the time or even none of the time.
That is the question … that I asked @Bencsi
Just a guess at this stage.
Hi Guys,
@John-M , @Wlodek , @BHAYT
To make the process more visible, I made a screen recording of a 4 images handling process in PL v8. PL v8 was not running at the video start and the last Preference for sidecar write was disable. Unfortunately the video sound is terrible, therefore I write here the process exactly. The link incl. the video and the test folder content. ( maybe the Edge browser need to login Google )
https://drive.google.com/drive/folders/1u3y7DRhg57NLoKgceGPz3MK2OjlrZmPI?usp=drive_link
I hope, the video prove my complain about VCs generation without my intention. PL - regardless the sidecar write state - start to make new VCs in case of unknown folder visit with old sidecars. Of course there are roundabout to delete VCs, but in case of a big folder …
If you need further test, let me know.
Endre
Oh, I can do that easily, but to what end?
@Bencsi Endre
Thank you for the Video.
On one machine the audio was inaudible but the advantage of having more than one PC is I switched to another machine and could hear your commentary (only just, but that was enough).
I believe that what you are seeing is something I may have seen before (a longish time ago so finding any post I made might be impossible) essentially every time you visit the directory the VCs multiply, even though you had the DOP write ‘Preference’ set off (or rather not selected) in this case.
I need to wake up an think about what is happening.
PL2 is about the only version of PhotoLab that I don’t have loaded and I have probably exceeded my licence count for that version but let me see if I can reproduce your problem.
Regards
Bryan
PS:- I lied, I have Photolab 2.4.0 Build 21 alive and well on one of my PCs so I can create images but it might be useful to have one of your images with a DOP so that I can make a mini directory and test it.
But I must ask, does this happen with all images from all copies of PhotoLab up to and including PL6, which I believe is the last version you licenced?
Hopefully, old version generated sidecars will not generate new VC in case of not yet visited folder content in a later PL version.
Endre
Hi Bryan,
The answer is YES. This phenomenon existing from Optics Pro v5. I was complaining several times, but never cured. Now, as a new version released, I tried again. That is all.
Endre
@Bencsi If you look at the table in my post above Unwanted Virtual copy generation - #40 by BHAYT I have the same image copied to a series of directories and then have accessed these in a number of release and created DOPs.
The reason I have more than one machine is that they act as backups for one another, in conjunction with a pair of 8TB USB3 drives.
So while I was conducting my test e.g. on my Test machine, one machine remains unchanged with the original DOPs, while I accessed the images with PL7 and then PL8 with a reset to the original values between the tests.
Using Beyond Compare I can then easily determine if any changes have occurred simply by “touching” (selecting) the images with the later release. In this case PL7 and PL8 have both overwritten the DOPs making going back to an earlier release impossible unless you have a backup of the DOPs.
So I understand why turning the “DOP write” ‘Preference’ “off” is important but once “off” that will then affect one source of “insurance” (the DOP) for any new edits you may apply to those old images in the later version and all edits you apply to any new images in the later version Sadly there is no easy way to “toggle” that option without a visit to the ‘Preferences’ screen!
I also wonder if this is what is causing the problems!?
When PL8 accesses the old OpticsPro image the DOP is considered incompatible (possibly the UUIDs are incompatible with PhotoLab) which is why it wants to overwrite the DOP.
But if prevented from doing that the old DOP remains even though the image is now in the database. Every time you return to the image directory the discovery takes place again and there could be an incompatibility between the UUID in the database and the one in the DOP so a new VC is created on each return to the directory!
Thank you for your forbearance with my posts in particular, they tend to be long and please put in another Support request and reference this Post and tell them that they have the knowledge to determine what bug in the software is causing it to act in this way so please fix it.
I will try some tests of my own in the meantime.
PS:- A simple test with PL8 discovery of each image in that test group with an image or two from each release with the DOP write option off did not cause the problem.
Beyond Compare showed no changes to the DOP (as expected) but revisiting the directory again and again did not cause any VCs to be created, another theory (guess) failed.
Test machine on the left, Control group on the right
Can you please supply an image, the shoes will do, complete with the original DOP so I can try that image because I am having a hard time trying to the recreate the problem on my machine(s)!
Thanks for the video, Endre … I was able to hear your commentary (with volume UP).
Yes, you have made your problem very clear to see - - but, unfortunately, it doesn’t help me to understand or explain it ! … It’s not something I have seen/experienced myself.
I wonder if the problem occurs if you were to access and navigate your test folder from within PL - instead of dropping files onto the PL shortcut (which is something I never do myself).
John
Bencsi,
Remember to report the bug. Apparently nobody has done that before - OR DxO apparently managed to ignore it? A new release with a well known bug… that says a lot about the organization around this product.
Hi Eigil,
It is sad, but true. This bug existing since I’m part of the beta tester group.
I found an Excel wish list from 2018. november which incl. this request.
The particular section looks like this
By the way, the#4. in the list is still existing bug, the scroll slider area in the Photo Library tab jump more rows, then visible in the list. Some item not visible just click on the vertical scroll bar. Have to step by step find the missing rows.
It was not in the priority list since than. In the meantime, I forgot the problem, just faced again, when I was looking for > 10 years old images, when I recorded sidecar files for every edit. In these days I do not use this feature - except for testing.
Endre
@Bencsi It is sad to see this error still present but I still cannot reproduce it, even though I saw it happening clearly on your video?
In the meantime I have a favour to ask of you, I would like a copy of your database, providing there is nothing especially personal contained within that data.
I am not seeking to spy on you but rather to get access to a large database to use for testing my programs!
Please see my DM
Hi Brian,
My recent database is quite big.
over 2Gb.
If you mind, I try to compress and upload to my Google drive.
The problem is, the Test folder already visited by the PL v8, therefore it will not handle the test images as new. The other database Photolab_1800-1.db is virgin from. It was the database imported from PL v7 and - maybe - it is not compatible with the latest PL v8. However, if you have a PL v8 version from the last year before 09/28/2023 , those have to be compatible and you can test the phenomenon. Please let me know, which database you can utilize.
The compressed size of the database file is ~140Mb. I can upload it to the same folder, you have access to.
I think you can simulate the situation to use any previous PL version to generate .dop files and open the folder with PL v8. I do not think, the database size is guilty.
Endre
@Bencsi Endre I currently have DxPL 4, 5, 6, & 7 up to PL7.9 installed on one machine or another. I am currently using the final PL8 release under a Beta licence which might expire at any time and I won’t buy a PL8 licence until Back Friday or when an offer appears, although a Trial is also already installed on an old i7 of mine.
So for preference a PL7 version (or PL6 version) because I can try tests on that and import it into PL7/PL8 etc. I particularly want a copy with ‘Projects’ because I want to see if I can code the dumping of ‘Projects’ from a database and potentially the restoration in another database, no promises and no timeframe commitments but I think I want to give that a try.
I have at least 2TB available on one or other of my HDDs and now have a download speed and upload speed of 500Mb! My major concern is as at your end to make sure you don’t exceed any limits of speed or space!
I make no promises about how successful I might be with the drive switching (actually very easy) or the ‘Projects’ dumping (with 200 projects in your database that should be a real test) but it should be possible and ‘Project’ recreation in another database - hmmmmmm, lets see if I can walk before I try running!!
Thanks
Bryan
PS:- With ‘Projects’ perhaps it should be
Talk to users of DxPL ‘Projects’ about their experiences and issues and what would be useful
Write a program to Vet the ‘Projects’ to ensure the links are intact and produce an optional report.
Write a program to Dump ‘Projects’ to a non database file and/or to a separate ‘Projects’ database, a basic extension of 1.
If 1 and 2 are successful, and I haven’t become too bored, look at putting ‘Projects’ back into a database from the flat files or the ‘Projects’ database.
Hi Brian,
I did upload the compressed “old” database to the Google drive. If you face to any incompatibility, let me know and I can upload the latest v8 compatible database too. The upload took me less than 2 minutes, probably download will be far less.
Endre
Hi Endre
Thank you for the database which contains the following
Source DB is present and correct
254746 Total of all in Sources
259535 Total of all in Items
254747 Total of all in Metadatas
230907 Total of all in iptc
2757 Total of all in Folders
96676 Total of isRaw in Metadatas
116 Total of Projects
With respect to my programming efforts the database is fine as it is, i.e. it will be subject to the rigours of my coding, or rather a copy will be subject to the rigours of my coding.
If you would like to send a PL8 database then I can see if I can use it to recreate your problem, i.e. by substituting some of my images for your entries in the database.
If you can supply an image and DOP e.g. a shoe image and dop, I can then copy it and give it the names of the other images you had in the directory then I can see if I can reproduce the problem!? I can’t promise I will be successful but it is worth a try I think.
Once again thanks for providing me with some raw data for my program testing or rather no thanks for supplying the database because it just broke my ‘Folders’ analysis program!?
It made the database copy successfully
and read a number of entries in the ‘Folders’ table and then crashed, i.e. the database did what it was intended to do and stressed (and broke) the program.
A job for after breakfast.
Regards
Bryan
PS:- Increasing the array size from 1000 to 5000 did the trick for now and moved the program on to the next bug!!
@Bencsi You have set me a greater challenge than I expected! Where does that database come from and what version of PhotoLab?
The reason I ask is that the layout differs, yours is the top one mine is the lower one
All the columns are the same but not in the same place, the ‘DisplayName’ and ‘NormalizedName’ in particular are not in the same column positions!?
Hi Brian,
As the date of the database file PhotoLab_1800-1.db shows is 2023.09.28. it was the last access date. It is funny, the SQLlite shows a different date. The UniqeID HDD identifier refer to a single HDD. At that time my system has been changed ( Win10 OS in a completely new hardware with a RAID1 incl. the N: drive ). Previously my OS was Win XP, where the E: drive included the same content, transferred to N: drive on the new OS. Actually - If you need I can discover - the RAID hide the 2 individual disks’ details. Such a long disk ID is available for other than N: drive is visible.
Endre
Endre It is not the contents that worry me it is that the database has a different layout to mine and I can’t fathom why?
I went back to old versions of PhotoLab and they do not put the "‘DisplayName’ and ‘NormalizedName’ where it is in your database!!??
But in SQLite is is possible to query the database for the name of a column
ColumnName$ = DatabaseColumnName(#sqlite, 7)
In my database that should be ‘MountPoint’ but in yours it will be ‘UniqueId’, somewhat confusing.
But that means that I can ask for each column name in turn and effectively “(re-)map” your database (and any other “strange” database) to the same layout as mine.
What had puzzled me was the output I was getting which looked like this
instead of what I expected which certainly wasn’t that!
Please ignore the fact that the column headings are not in the right place, I am trying to get useful data out of the program and will re-align headings etc. later, probably 
.
Hi Bryan,
It seems the folder list is not very fresh, there are folders I visited >10 years ago. E.g. the 'DXO 9 project" folder content is 10 years old.
If you mind, the sidecar generation bonded to the database error, I can not disclose, because it consist of database history since 16 years. Fortunately I have a lot of previous Optics Pro and PL database. If you mind, I can compress and send you several versions.
Endre