I recently noticed some weird behavior with PhotoLab 9 on my Mac Mini. It is so strange that I have a hard time believing it happened the first time but it just happened again so I have to post about.
I have a directory that probably has several thousand files in it that were all shot at one location while I was on a trip. I was scrolling through the files (in PhotoLab) looking for something interesting to edit in PhotoLab and all of a sudden I noticed something changed on the screen. All (or many) markers on photos indicating that they had been processed disappeared. At the same time, I noticed that all of the editing details for these files were gone as well. It was if nothing had ever been changed in the photos.
Since I use a NAS for storing my files, deleted files are simply moved to a separate directory (or trashcan) temporarily. I looked in that location and immediately saw a large number of .dop files had been deleted and moved there. I recovered them by simply dragging all of the files back to the original photo directory.
I did a periodic cleanup of the NAS trash can within the last hour and permanently deleted all of the files that were there.
In the last few minutes I went back to editing photos in this same directory and duplicated this mass deletion of .dop files. Suddenly there were another large group of .dop files in the NAS trashcan. I can recover these files again but it is really weird to see something like this happen while I am just moving through the files in PhotoLibrary.
ā¦that is the scary part. Therefore, we need to proceed carefully.
As a first step, Iād make a backup of the database and then uncheck sidecar import and export. After that, Iād manually export the sidecar of ONE image. If it gets back its edits and metadata, the database seems to have survived. You can then select a bunch of images and export sidecars manually again and again until done.
I do have sidecar import and export checked but metadata synchronization is not enabled. I wanted to do some tests on a duplicate directory but I think I have run into some more conflicts with PhotoLab behavior. Since the real information about changes is in the database not the .DOP files, I canāt duplicate all the information by just exiting PhotoLab and copying files in the Finder. When I did this, I lost a huge number of image modifications and PhotoLab was forced to generate brand new .DOP files.
But now that I do have all the RAW images in a new location I can try and reproduce my original scenario and try to determine what has happened and if it is really a bug or something I introduced inadvertently. I donāt think the fact that .DOP files were unexpectedly deleted is the issue that apparently happens all the time when photos are touched in PhotoLab. I need to verify if the actual changes in the database are lost and how try to understand the exact steps that caused it.
Rewriting the sidecars can possibly leave an image without its sidecar for a few seconds, but Iād not expect them to be all gone at onceā¦ For better control, I set PL to NOT automatically import or export .dop sidecars. I do it manually when I start and end a session.
Also, if (all) my edits were gone, Iād be worried. PhotoLab isnāt that good in keeping its database in good shape, but itās not been so wicked as to āremoveā my edits yet.
If edits AND .dop sidecars are gone, there is nothing that will save your bacon except a backup.
Iāve posted a few lines about how to force PL to export .dop files. It involves editing a copy of the database. If thatās not your thing, you neednāt look for the post(s).
This is a bizarre situation. Iād be tempted to suspect one of two things:
macOS Finder. Iāve noticed lately that it can be a real mess when it comes to displaying the truth of what files are where. This includes simply not showing some files, which would fit your situation. It also uses the wrong icons and file type labels. If youāre not already, check the contents of the NAS by other means ā if a Synology, then with FileStation, otherwise something similar or, last resort, Terminal.
macOSās handling of network shares. Now, I have not had many issues since I got my Synology about a year ago, but file shares to other Macs have been notoriously problematic. One problem I had both with other Macs and the Synology is the inability to delete certain files. Maybe the inverse could also be true. I have a vague recollection of a discussion on a recent Accidental Tech Podcast of someone who had tons of files get suddenly deleted.
I am currently experiencing exactly this behaviour. Trialling 9.6.0 b43 (downloaded yesterday) on Mac Sequoia 15.2. My photos are located on a Synology NAS, hardwired directly to the computer via 2.5G ethernet.
I have a folder containing 1138 photos. 117 of these were picked; this morning I began editing. At lunch I noticed it said only 84 photos picked, and then a few minutes later 71. I had noticed that when browsing the photo library it would take a few seconds to recognise picked photos - initially saying ānoneā, before most and then finally all were accounted for. I believe it simply wanted a quick recount; I restarted DXO and then the Mac.
Within the Photo library in DXO I examined the folder to discover that most of photos I had picked were no longer marked as such - and alarmingly had no edit history either. Then as I was re-picking the photos in the photo library, before my eyes DXO refreshed the folder and even more picked photos were unpicked - Iām now down to only 24. I checked the folder in Finder and most of the .dop files have been deleted.
In what circumstance would DXO choose to delete a .dop file? I have lost a morning of edits and significant faith in DXO as a dependable piece of software. I have been using PL5 for many years and have never encountered this problem. All of my photos have always been located on a Synology NAS without issue.
I have serious doubts about wanting to upgrade now - clearly this is not an isolated issue.
If the issue is related to NAS-handling indeed, Iād presto copy the photo archive to a separate SSD attached directly to the Mac. Maybe using Carbon Copy Cloner to do so. CCC can verify transfers if set to do so.
Even though you have a high speed LAN connection, your NAS drives are still the slowest part which could, in combination with PhotoLab writing sidecars asynchronously, lead to timeouts that are then āfixedā, leading to said data loss. PL was never designed to deal with photos on a NAS (I presume) and losing more work/effort is not something Iād be keen on.
Again, keep your photos technically as close as possible and i/e dop files manually.
One more thing: 1138 photos in a folder is beyond what Iād consider to be a reasonable number for PhotoLab. Iād probably split that folder into 4 (or more) parts.
Whilst I accept that editing files stored locally or on an SSD may be more efficient, it seems unreasonable to expect users to either a) keep all of their photos stored locally or b) do the edits locally and then transfer the files to more permenant storage after every shoot.
I edit 6K raw video straight from the NAS without issue and Iām not the only person to work directly from external storage. Itās suspicious to only experience this on PL9 - and on the first day of trialling it too.
Over 1000 photos a day is quite common for wedding, sport or wildlife photographers. I separated this project by day into separate folders - with over 7000 photos in total. Again, I donāt think itās reasonable for DXO to expect users to artificially limit folder sizes. It is (or should be) a professional, robust piece of software. PL5 never struggled.
I fully agree that PhotoLab has known limitations which are discoverable in documentation (even if you have to dig through it) which can be used to say āthis is not the right app for you.ā
But for a fairly reasonable situation where a user:
stores their photos in a NAS drive
keeps some folders with 1000+ photos
there should never be a situation where the application is actually discarding user-input data, and then we say āoh, thatās just PhotoLab for youā when thereās literally no documentation that says this can or will happen. And then if that was the case, the app should warn you that you are getting into dangerous territoryāanything less is insanity, as far as an app goes ā especially when relying on it for work of any kind.
What the OP is describing is bona-fide bug, not simply a limitation, which DxO should recognize and fix. Otherwise their product and their company simply are not professional.
Earlier versions of PL did just that, but I havenāt experienced it with PL 9 so far.
Hmm, a few of the unfortunate patterns have been designed into PL and although many posts have addressed these unwelcome patterns, DxO has not yet found the time to make PhotoLab as robust as any pro software should be.
PhotoLab software development revolves around breaking the 20/80 barrier regarding technical quality. Therefore, PL is a really good plugin for any other app that delivers pro level asset management functionality and reliability.
Minor update. I perservered with editing today. Finished editing the photos in that folder with no problems. Successfully exported 97 photos. Went to export them again in a smaller resolution and noticed only 73 photos were now picked.
I began a screen recording and identified the 24 missing photos by comparing the exports with what remained picked in PL. Checked in the source folder and as suspected, the .dop files were missing. After the first instance of this happening the other day, Iāve enabled the recycle bin on the NAS and found the sidecar files in there.
These 24 missing photos were now unpicked in PL9 and had no edit history. Whilst examining the 73 files, a further 4 went missing during the screen recording.
I continued to try and induce more to disappear (going in and out of the photo library, selecting/deselecting all, exporting), but could not reproduce it again.
I restored one of the sidecar files to its original folder and imported in PL and it did restore the picked status and the edits (but not the complete history).
I have opened a ticket with DXO and sent them this screen recording so letās hope theyāre able to identify and fix this issue.
I received a reply (and potential resolution) from DXO support. Their response was as follows:
Thank you for your patience while we investigated your case.
Our development team has completed a detailed analysis. This turned out to be a complex situation, and weād like to share both what weāve improved and what weāve identified as the root cause.
We have implemented a partial fix that prevents sidecar files from being deleted when images temporarily disappear from the folder.
This fix will be included in the next PhotoLab 9 maintenance update.
With this improvement:
If images temporarily disappear and then reappear, your edits will be restored automatically (provided sidecar auto-import is enabled)
The only limitation is that the history of edits may not be preserved
Our investigation indicates that the main issue is not caused by PhotoLab, but rather by a known limitation between macOS Sequoia (15.2) and SMB network shares.
In certain cases, macOS may:
Not correctly display all files in SMB folders
Temporarily lose connection to network storage
Struggle with folders containing a large number of files (such as your Synology setup)
This behavior has been reported by other users and documented here:
[Third link removed in order to post. Search for Gaelan Lloydās blog post entitled āFix macOS Finder problems with Samba file sharesā]
To help mitigate the issue, we suggest:
Updating to the latest version of macOS, as improvements may have been introduced
Optionally reviewing SMB configuration settings on both your Mac and Synology (some users report improvements, though results may vary)
We understand this is not an ideal situation, but we hope the upcoming PhotoLab update combined with these recommendations will improve your experience.
Just tested with a NFS share on an ancient WD MyCloud device.
The share was relatively easy to create (YMMV) and accessing it with NFS used the following to connect:
nfs://192.168.1.33/nfs/testpictures
The share came up in PLās browser and presented the images after a short delay that is to be expected with the gear and connection used.
I addressed the share ātestpicturesā with its IP address and corresponding path.
The share was set up to be accessible from the IP address of my Mac.
Terminal.app was not used, everything was GUIād.
