re-indexing simply adds whatever DPL finds…but it does NOT clean up things that are gone by deletion, moving, renaming etc. You also noticed as you write.
Exactly. I confirmed this in another thread.
If re-indexing pointed out the files and folders with problems and gave us the respective choices, we could make/keep the database fairly useful.
A tiny little first step could be the following:
- Allow to delete images that display with a ? instead of a preview.
We’d need filters and sort possibilities for such a case though.
1 Like
It is really no problem for me. Normally I just starts with deleting the datatabase and restarts PL. Then just points to my top folder and reindex. I never uses “Projects” and if they can’t preserve it’s siblings “External Searches” I can live with that too because they mostly are interesting just when they are fresh.
If someone deletes files in a subdirectory with JPG-derivates of RAW from outside PL you just need to delete just that folder inside PL and then reindex just that folder.
In fact is isn’t even needed to delete the whole database because a reindex will index your present file strukture and files if it just is about not needing to see orphans because a new index will not show these anyway in practise. What we are talking about here is more of an academic question that the database is “polluted”.
To be fair not even .DOP-files are handled properly because I don’t know how many times I have deleted orphaned DOP-files too over the years.
Probably old DXO-developers are still stuck mentaly with their old sidecar solution to care all that much about the database. For them I’m pretty sure the DOP-files are the “real thing” and the database is something they developed to be able to write “we have one too” in case somebody would ask.
If it would have been more central for them, I am absolutely convinced it would have had a totally different status from what it really has today.
The database can cause a lot of problems if you usr more thsn one computer with your imiges. Laptop away and desk for home can lead to lots of problems thst have endlessly been covered here. The only reliable way is using a dam program and dops. DxO have never sorted the database problems despite saying they were going to introduce managment options nor sortrd using PL on more than one PC.
There are problems and the most common I guess is that PL is so rigid and doesn’t support changing the XML-schema/data elements at all. That causes problems when I export my JPEG-files.
In PhotoMechanic I use an element called “Event” that is used together with the “Location”-set of data. When I export JPEG-files from PL that data gets stripped since it is not included in the IPTC/XML-schema of PL.
With more competent DAM like PhotoMechanic and iMatch that is not a problem but one reason for me to migrate now is that PhotoMechanic is not fully converted to XMP like iMatch is. Internally PM is still IPTC which even many converters also seem to be including Photolab and Capture One.
When using external software I have never seen any systematic problems with updates when synchronization has been on in PL and it reads the XMP-files except for missing elements in the PL-schema. Even that can be fixed by not using that element in the external software. That is my choice.
There is and has always been a rule of thumb to never conduct bidirectional updates. One software must always be the dataowner.
New info -
Got the same message just now. At about the time I last used PL8 I updated several folder names. I started doing this through PL8 until it couldn’t update one folder because it said it was in use somewhere else. I couldn’t identify where else, so I shut PL8 and updated the folder names using Windows File Explorer (Win11).
Now, some days later, I open PL8 and get the error again.
With LightRoom 4, if you modified folder names outside of LR, LR will still show the list of folder names that it previously knew about - ie. the old names - but they will be greyed out, indicating it can’t locate those folders on disk. At this point though you could click on a folder and opt to “find” it on disk. A dialogue box appears and you navigate to the new folder name and submit that dialogue box. Presto, LR now knows the new location and name of the folder.
It seems LR8 in this scenario throws its hands in the air and says “I have to build the whole thing from scratch”.
I really wish there was documentation published by DXO explaining exactly what information is contained in the database - so we had some understanding of the impact of this error message.
I haven’t had the time to try looking at it with a relational database engine (but also, I shouldn’t have to).
1 Like