Indexing multiple folders - is it broken?

Hi,
I have just been revisiting the file management capabilities of PL4 and believe that the folder indexing fails with any folder that contains sub folders. My collection of images is on a USB 2 drive and images are stored in folders named by date shot. All these folders are inside a single parent folder. When I select the parent folder the index appears to start and a side to side indicator is shown. The indexing never finishes and the drive and the computer remain quiet i.e. the cooling fans do not switch on. However, if I select the folders one at a time the noise level increases indicating that some processing is taking place. It seems to me that the indexing process fails when processing nested folder structures so I wonder if others see this? I am running PL4 on Mac OS Big Sur.

1 Like

I’ve just indexed my photo collection again and found that DPL 2-5 actually do include subfolders as well as folders linked with an alias.

How did you index your photo collection, @platypus? There’s a little text “Ordnerindex anlegen”, but the German manual doesn’t tell anything about. Why did I think, paid software has advantages? Like well translated UI texts, helpful manuals … at times I really feel being naïve.

For a complete database replacement, I did the following

  • open Terminal.app
  • enter “caffeinate” and hit Enter (prevents sleeping)
  • open DPL and select a folder without images
  • quit DPL
  • delete the database
  • open DPL
  • click on the icon left of “Ordnerindex…” (see screenshot below)
  • in the popup, navigate to the root of your photo collection
  • click OK and have dinner while you wait
  • when the progress bar has stopped moving, wait a minute
  • quit DPL
  • open Terminal and press ctrl-c, then type exit, hit Enter
  • quit Terminal

My Mac took about 30 minutes to index 25k items.
Bildschirmfoto 2021-12-11 um 19.18.58.431

BTW: I’d welcome that function in the file menu and/or if had an icon that can actually be noticed.

Very intuitive process [/irony] :grin:

Database replacement sounds always a bit like “last possible exit out of this mess.” :face_with_thermometer:

HI,
As this thread has bumped I’m trying to index my photo disk to see if Photolab version 5 completes the re-indexing task. My images are stored on a USB 3 SSD drive inside a top level folder and a number of sub folders. An example path to a raw image file is /Volumes/Photos_SSD/Library/2018/2018-02-09/2018-02-09-153629-1090083-Lens-Test-.RW2. I started the re-indexing of approximately 1TB of files at 08:33 this morning and will report back if and when PL5 finishes.

The PL database is somewhat contentious on these forums. Simply it meets some but not all user’s needs. I’m in the does not meet my needs camp and would rather see programming effort put towards integration with third party tools and image processing. However, full disclosure, it is likely that you would find my image file management odd but I have arrived at it as a method that works for me and does not rely on any database or metadata. My system relies on modifying the filenames which causes PL and other applications to complain from time to time so I frequently trash the PL database but I do have PL create sidecar files so recent edits are preserved.

S

08:50 - still indexing, no sign of disk activity/fans etc.

Deleted the databases of DPL versions 2 to 5 and re-indexed my photo collection after restarting DPL. Note that I ran the versions in parallel, starting with DPL5, then 4 etc. within a minute approx.

6 minutes into the test. CPU load looked like this:

15 minutes into the test, DPL 2 and 3 had finished their work:

29 minutes into the test, DPL4 had finished:

A few seconds after that, DPL5 had done the job too:

All DPLs ran minimized, under macOS 11.6.2 and “caffeinate”,
which prevents sleeping.

These were the shortest times I’ve measured for indexing runs so far.
All databases showed the same number of ingested image files (25k).

Computer:
Bildschirmfoto 2022-01-09 um 15.09.42.882