PL5 version 5.3.0 and 5.3.1 issue

Good morning!

  • Yes, it means that the full folder can’t be loaded due to some corruption. Could you, please, try t reproduce the crash with ‘Refresh’ and press “Do not send” in the crash window?

Then, please, provide me with the logs + crash report:
Crash files – %UserProfile%\Documents\DxO PhotoLab 5 crashes
Log files – %UserProfile%\Documents\DxO PhotoLab 5 logs
You can attach them here or via upload.dxo.com and let me know when ready.

As a workaround you can use suggestions given by the guys above.

Thank you
Regards,
Svetlana G.

Not setting any filters does not mean that you don’t have any filters set. Filter settings carry across sessions and do not change with the viewed folder. Have you looked at the filter list and confirmed none are set? If so say it. Maybe we have a language difficulty.

When you copied the files to another folder they are no longer associated with database entries. Database entries which contain status which can be filtered on or possibly corrupt entries preventing image display.

Yes, it sounds like database corruption to me too.

Just a clarification here, (tho, not for Platypus, who I believe doesn’t use Sidecar/.dops by default).

If you have the default settings in Preferences then Sidecar/.dop files will be used - and, therefore, all your previously applied image corrections/customisations will be saved therein - and will be re-applied the next time that PL “discovers” the images (and their related sidecar/.dops).
image - This is how I work … I always delete the database.

“Metadata” (tags, ratings, etc) are stored only in the database, tho - so you will lose them if the db is deleted.

In that case, if you can live with a change to your Folder-name - then that would be the simplest “fix” (aka, workaround !) … You could add something as simple as an underscore to the end of the name.

John M

…my proposal is also aiming at getting rid of orphaned items in the database. CAVEAT: Until DxO adds housekeeping functions, orphaned items will just creep into the database anyway…so the simple rename (outside of PL) seems okay for the moment.

For those who want to find images through searching with PL’s search functionality, regular DB cleaning can help to avoid to find things that don’t exist any more or to not find images that are still there…

I didn’t see it mentioned but to prove that you don’t have any filters set select Filters then select Reset.

I copied and renamed all outside of PL.

Hi Svetlana

I have uploaded the log file but there was no crashes folder at that ‘path’ location ???

Edit ~ I reran the F5 to get the crash and then looked at “the files that would be sent” to identify where the reports were being stored…I have now uploaded the log .txt file and the .xml crash file.

I look forward to learning what you find from them :slight_smile:

I have had a look at what you suggested and the ‘Reset’ in the filters list is greyed out and not clickable…AFAIK that means(as I said :wink: ) that I have not set any filters.

I figured that was the best way to “prove” the point. And get folks to move on. ;o)

1 Like

… which is guarantee for difficulties.

Oh!!! I thought that was the optimal way…in the situation I was experiencing…but apparently not?

Are you able to explain, the differences between what I did and what would/should have happened if done from within PL ?

TIA :slight_smile:

When an item is moved or renamed in PhotoLab, PhotoLab can track the change in its database.

When an item is moved or renamed outside of PhotoLab, PhotoLab can have no clue of the change - and the moved/renamed items will be added as NEW to PL’s database. This means that, according to the database, the item exists more than once.

1 Like

Also;

  • When renaming from within PL, PL will ensure that change to name of the image-file is exactly replicated in the name of sidecar/.dop files.

  • But, if renaming from outside PL then it’s entirely up to you to be very careful to ensure you keep this same-name relationship intact.

  • And, if you are renaming from outside PL then it’s safest to ensure that PL is not running/active at the same time.

All the same, I do this all the time - because I don’t use the database at all. I delete it at the start of each PL session (using a “wrapper” to invoke PL) … and I depend only on sidecar/.dop files.

John M

2 Likes

Thank you. Got them and one of our developers is investigating them.

Regards,
Svetlana G.

Hello @BoxBrownie

Thanks for your report.

I have investigated your logs and it appears that some files are missing in the filmstrip because of a database corruption on this specific folder (F:\2022\Fox_Hide_22nd_JUNE_2022_OM1). You should have a red cross next to the image count in the filmstrip when you browse this folder.
Could you send us your databases for investigation (you can zip and send us the folder C:\Users\Laurence\AppData\Roaming\DxO\DxO PhotoLab 5\Database).

As proposed by the other members on this thread, the easiest workaround is to rename the folder to have all the images displayed.

Thanks

1 Like

Hi Gregoire

Thanks for the update.

As I mentioned in another post…I do indeed see the “red X” against the image count in the flimstrip :slight_smile:

In regard to the resolution, I will from within PL5 delete the folder with the problem and re-rename the one I created to make it cohesive with my folder naming structure. All within PL5 so that the database can ‘work’ properly (NB this based on the advice, above, that I read and hopefully understood correctly)

I have sent you the requested ‘zipped’ copy of the database and await your further insights :slight_smile: