6.0.1 has been out for a while.
checked your referred post – 6.1 will be coming then 
Yes I believe it’s scheduled for December.
That’s about the # of thumbnails it stalls out for me too. Doesn’t matter if it’s from different folders either. It seems to be total loaded since last software restart.
Possibly a DPL on Win issue.
Got no stalls with DPL 6.0.3.33 on macOS Monterey on iMac 2019.
Tested with a folder containing >1200 CR2 files plus respective XMP sidecars from Lightroom for a total of about 38 GB of data on the drive.
Memory load went up to almost 1GB out of the installed 40 GB. No swaps.
I already have a week or so ago.
And to those who believe this is about numbers: I don´t think it is:
Images not loading until you click on the one at the time - DxO PhotoLab - DxO Forums
As you can see in the case I have documented, I only have 12 TIFF-files in the folder my PC managed to hang.
I run Windows 11, i7 gen 12 processor, 16 GB RAW, 1 TB SSD-disk and a good graphics card in a new Gaming ACER Predator machine that use to process 33MB RAW with Deep Prime between 3-4 seconds and Deep Prime XD in 7-9 seconds. So I have hard to believe it´s something wrong with my machine performance.
So far nothing has happened with the support case I registered except a mail. I think it would be good if DXO could take the time to participate a little more and come back to us in one or another way.
I think this problem might be related to the more extensive use of the catalog/database in version 6. Both Lightroom and Capture One have had and still have issues with performance. When People upgraded from version 20 to 21 of Capture One, and using the general database mood (C1 has a Session mood too) there was the same type of complaints about performance.
I had severe problems long ago with both Lightroom 5 and 6 and after studying Kirk Bakers Lightroom manual I underdstood there is a performance cost in a system that consists both of a databas/Image Library and a RAW-converter. The ImageLibrary needs small previews to be fast when users want to cull their images but they don´t want those previews when postprocessing their RAW/TIFF or DNG. Then 1:1 previews are more ideal.
In Lightroom they had a lot of different choices here to make and they were all compromises and so is the case in Photolab. In version 5 we had to zoom to RAW quite a bit before the system scaled a high-resolution preview.
To take another example: Photo Mechanic Plus 6 which is a highly specialized culling and metadata editing tool. It is fast as a flash because it is specialized and don´t have to compromise when it comes to the previews, like the compromise plagued RAW-converters of today with integrated image databases.
Normally I use to integrate Photolab with Photo Mechanic and one of the really important reasons doing so is that I can avoid problems like these by searching/finding/selection what to open in Photolab with the “Edit selected photos with - Photolab.exe” in Photo Mechanic. It works fantastically well when you don´t have to wait always for a whole folder to get a refresh of the previews. Here it will instead always open just the images you want to work with for the moment - it might be a whole folder but it might also be limited to just a few selected images.
… and if you are into metadata editing - don’t do it in Photolab - do it in PM Plus instead because it´s so much more effective. If you just turn on “Synchronize” in Photolab all the metadata changes will be replicated to Photolab immediately.
I suppose it has to do with how memory is managed by the app and the OS…
Win 10. 1612 images, wide gamut, 2 minutes, max. cache 5400MB. No problem.
George
We don´t know at all. I don´t like to speculate - am just documenting the error. DXO has to make some empiric tests with a debugger on or so. Mostly it works as it should for me sometimes not.
It´s all about the preview rendering.
@George
We don´t have these problems all the time but sometimes it happens. If you walk my link above you will also see that it´s possible to get images too load one at the time by clicking them manually but try that with a batch of 1612 images when it happens. Not an all that practical fix for most people I suppose.
I’ve seen your thread “Images not loading until you click…”, as you get get the message “loading, please wait” before you click on the preview (thumbnail). I’m sure this is the same issue as I reported to DXO Support back in October. DXO Support/development have confirmed they have found what is causing this issues and the fix is scheduled to be included in release 6.1.
@LJC
Thanks for that input. Then we can look forward to version 6.1 I suppose.
I also upgraded early to version 6 but it took a while for me to get exposed for this problem. Still I see very clearly that it takes a while for Photolab 6 to refresh the previews every time I open a folder with say 500 images.
Before we complained about the time it took to refresh the image we were working on when zooming and now we complain about the fact that it always seems to render new previews for all images in advance in a folder as soom as a we open it.
There has to be a compromise when integrating an image library with a converter but the question is how that compromise will look and work and what will be favorable for most if us. It’s also very dependant on the processing power we happen to sit on.
The intresting with the present version and it’s problems has been that even we that have new and fast machines are affected.
Are you saying you don’t get this problem at all? I get it all the time.
Anyway the fix is coming, which might be January now though.
@Tbolt @George @LJC etc. This is related to my topic Win 10 DxPL6.0.1 Can't handle large directories - thumbnail refresh fails where I was using two directories one with BULK images 11,960 to be precise and another Bulk directory with 1,000 images.
I decided to see if there was any way to avoid the problem and moved my Cache from a DATA SSD to an NVME, however that NVME contained the database and the actual files themselves but I loaded the initial BUK (11,960) images and scanned all thumbnails and all were present!
So this is the incomplete post I started:-
@LJC, @IanS, @roogirl While I look forward to the fix I decided to move the cache from where it has been since PL4 to my NVME drive, so two changes there
- The action of moving the cache and restarting PL6 with the new setting
- The cache moving from a SATA SSD to an NVME (not the fastest NVME but …).
So we have on H:, (the NVME):-
- The PL6 Database
- The Cache files
- The actual 11,960 BULK image directory
I believe that the initial discovery of the 11,960 BULK directory went much slower than I expected (but had failed to time it - sorry)!?
However I have traversed the directory from one end to the other with no apparent issues, please note that the 11,960 images are also held on the NVME drive (as is the database and now the cache)!
It looks as if a lot has been taken over from E: (Sata SSD) to H: (NVME) when I moved the cache directory!
Most screens still show the “render swirl” but no ‘Loading please wait…’ issues.
Switching to the 1,000 image Bulk directory (also on the NVME) took about 2 minutes and 20 seconds to load and no problems encountered traversing the structure in PL6!
So I copied the 1,000 images to F:, my main HDD and included the 11,960 BULK directory and tested as follows:-
- 1,000 Bulk images without any sidecars 1 minute & 25 seconds and no problems traversing thumbnails.
- 1,000 Bulk images with sidecars 3 minutes & 4 seconds and no issues with thumbnails.
- Navigate to BULK directory on H: (the NVME) 13 minutes &54 seconds and no issues with thumbnails
I then opened the Bulk directory and they were all correct and finally I tried opening the BULK directory on HDD and either 54 minutes or 84 minutes later (I was using a conventional stopwatch and getting on with Lunch and DIY etc.) DxO had finally accessed the directory and finally the problem resurfaced.
I now have BULK on a USB3 SATA and will clear the database and start testing again and then update this post!
They often do, even when the ingestion is done. I’ve seen this for a few years now and mostly work around the issue by switching to an other folder and back.
@platypus That will cause PL6 to rediscover the directory all over again, not something you want to do if it has 11,960 images in it!! The swirling “render” icon doesn’t stop the product working providing it hasn’t actually encountered “the problem”!
My tests reported above, after moving the cache to NVME, were all undertaken in one session and all worked perfectly, unless I was living in an alternative universe!? I didn’t understand that at the time and after last nights testing definitely do not understand them!
Firstly for those that like to treat their images as unstructured “blobs” with no subdirectory structure then the best of luck! This is XnviewMP discovering the images on a USB3 SSD for the first time (it also builds a database)
and this is PL6 re-discovering them (and encountering the “problem”) last night, one of many tests all of which failed!!
A repeat just now actually completed the re-discovery from NVME (with the database now on SATA SSD) and the counter reached “11960 images” in 03:44.63 minutes and I refrained from any scrolling through images until the counter showed 11960!.
But the ‘rendering’ needs to take place as the display is scrolled and I then encountered the following (please note that there are some thumbnails being displayed in amongst the “chaos”!
All the tests I reported in the post above had no scrolling from an impatient operator (me) until the counter reached 11960!
During my test last night I scrolled down the images while the discovery or re-discovery was in progress and every test failed regardless of the location of the database which was cleared before every new discovery test. Discovering from HDD is just a nightmare but from NVME was just over 19 minutes and from USB3 connected SSD was just over 23 minutes.
So I have no magic bullet other than using XnviewMP to break large numbers of images into smaller batches and passing them to PL6 and making them into projects in an attempt to keep the numbers relatively small but I would only attempt that on up to 1,000 images breaking into 3 batches and only if it was important to process those images!! This is using another piece of software to navigate and PL6 to process the images (as a “workaround” until the fix arrives)!
Once PL6 “breaks” then, as I found last night, all further attempts to process even small directories failed to display the thumbnails correctly, but I have successfully used PL6 to process such images, i.e. navigating “blind” does not stop the main image from being presented and processed (hence navigating externally and then processing in PL6).
For reference:-
My drive configuration during the tests was C:, E:\ are SATA SSD drives, F:\ is my main HDD, H:\ is the NVME drive (fitted to a card rather than to the motherboard to keep all SATA ports fully active) and I:\ is the USB3 SSD.
I only moved the database for some tests from H:\ (NVME) to E:\ (SATA SSD), the Cache remained on H:\ (NVME) throughout and the images were confined to either H:\ or I:\ no tests were done last night with the images on F:\ (life it too short)!
Having 12k image files in a single folder looks foolish to me.
Pointing DPL at a 12k image folder will obviously result in annoyingly long waiting because of the amount of previews that will be rendered - and I suppose that the cache will be overwritten too, possibly resulting in another round of rendering activities.
Indexing 25k image files (no sidecars present) in a folder structure takes about 30 minutes on my Mac, even if I let several versions of DPL index the structure concurrently.
1 Like
@platypus Indeed it is but some users have such directories which was why I created it about 1 year ago!
and it is but locating the files on Sata SSD or NVME keeps that to 24 minutes or less (!) and PL5 can cope with that many files without the problems being experienced with PL6, hence the fault report made by @LJC.
Because of the size of the directory it seems clear that DxPL reads all images first and creates the database entries and then renders as required thereafter. Quite what happens to the cache, and when, I am unsure but the tests that I conducted just after I moved the cache to the NVME all worked successfully and were conducted in a single session with PL6.0.1 without a single mistake!!
But since that things appear to have deteriorated substantially!!
My aging I7-4790K is obviously no match for your M1 Mac which is hardly that surprising given the difference in “age” of the silicon involved, although I had two TV programs being recorded to HDD last night (late evening) at the same time!
The “only” value of such tests is to stress the software unfortunately it can also “stress” the user!
Just finished a foolish test.
- Copied all my CR2 files to a Samsung T7 SSD (330GB, 14329 files after copy)
- Let DPL index the T7 (just the RAWs, all flat, no folder structure) 30 minutes max
- Pointed DPL at the T7. DPL took approx. 135 minutes until all images were “unswirled”.
DPL did everything without stalls, messages etc. and the database now lists a total of 14389 files including my separate 60 files test folder. All seems well.
Tested with DPL 6.0.3 on macOS 12.6.1 on iMac 2019 (3.6 GHz 8 core i9, 40GB RAM, 2TB SSD) + Samsung T7 (2GB). Let DPL do its job and did something else while it was crunching.
Rediscovery: Restarting DPL and pointing it at the T7 again (after having parked it on an empty folder) starts the rediscovery, but the twirls go away as soon as a set of images appear on screen.
From that test, I’d guess that the issue (ref. title of the thread) has to do with the OP’s non-Mac environment and its specifications.
I note that v6.1 has been released but in the ‘bug fixes’ it does not mention this issue one way or the other?