Lightroom 9.0 is out

[john beardsworth]

As usual with the way Adobe release new features with dot versions, this isn't a major change. The main new features are:
- content aware fill for panorama edges
- run multiple export presets

[digitaldog]

And a new splash screen; that's HUGE 
But a few more useful items outlined here:
https://www.lightroomqueen.com/whats-new-in-lightroom-classic-9-0/

[Christopher]

wow what a das Update. Once again no psb support or larger files.

[kimballistic]

I wonder why we still don't have .heic as an export filetype option.  The quality and/or storage improvements sound substantial.

[Chris Kern]

a few more useful items outlined here:
https://www.lightroomqueen.com/whats-new-in-lightroom-classic-9-0/

Any precautions we should be aware of (other than having current catalog back-ups) with respect to the new data format?  For once, I found Victoria's explanation less then enlightening:

This release upgrades your catalog format, so you can’t easily roll back to 8.4.1. Adobe also moved the Sync.lrdata file to sit alongside the relevant catalog to improve performance and reliability.

For those of you have been Beta testing this release, any hiccups?

[digitaldog]

For those of you have been Beta testing this release, any hiccups?

No, but that's no reason NOT to backup the previous catalog and keep it around awhile.

[Chris Kern]

No, but that's no reason NOT to backup the previous catalog and keep it around awhile.

Of course.  Goes without saying.

[digitaldog]

With this new version, your 8.x or earlier catalogs will be upgraded but the Catalog upgrade creates a new copy of your catalog, so your existing catalog remains intact. Still, keep it around awhile.

[Alan Goldhammer]

With this new version, your 8.x or earlier catalogs will be upgraded but the Catalog upgrade creates a new copy of your catalog, so your existing catalog remains intact. Still, keep it around awhile.

I have catalogs going back four versions!!  Never felt the need to delete them and one never knows in this day and age when they might be needed.   

[mtakeda]

I load the image files to two external hard drives( one primary and the other backup) and wonder I still need to do the backup of the library after post processing each time?

[digitaldog]

I load the image files to two external hard drives( one primary and the other backup) and wonder I still need to do the backup of the library after post processing each time?

If you make through and regular backup's off all changed files, no, not unless you want multiple backup copies. You can certainly turn OFF LR's lame backup catalog option.
I have a dedicated drive for my catalog, all images and LR files and it's automatically backed up to the cloud and an external drive every night. I also swap external drives; one for a fire proof safe, one for travel. Then rotate them. So at the very least, there are two backups per day of all this data should it change from the day prior.

[Chris Kern]

You can certainly turn OFF LR's lame backup catalog option.

Question: is a locked Lightroom catalog guaranteed to be in a consistent state if you subsequently need to recover it?

I have been using the back-up catalog option on LR process exit.  But I also have a script which backs up both the active catalog and the saved ones to a high-availability server every 15 minutes (and the back-up copies are then backed up to another server every hour).  My rationale for using the internal LR back-up feature has been that while the program is running, the database might be in a less-than-fully recoverable state.  I delete the oldest catalog back-ups every now and then (I guess I could script that, too), but at any given time they consume between 5 and 10GB of mass storage.

Am I missing something here?  Is the LR back-up-catalog option providing any potential benefit to justify the space it consumes?  I haven't been able to find anything on the Adobe website(s) that explains how the program manages its dataset.  Does a running instance of LR flush the database at regular intervals to insure consistency?  If so, what does the "optimize catalog" option do when it is invoked?

[digitaldog]

Locked catalog?

[Chris Kern]

Locked catalog?

I.e., while Lightroom is executing:

-rw-r--r--   1 ck  staff    72B Nov  5 15:04 Lightroom Catalog-2-2.lrcat.lock

[digitaldog]

I.e., while Lightroom is executing:

-rw-r--r--   1 ck  staff    72B Nov  5 15:04 Lightroom Catalog-2-2.lrcat.lock

Check when running in Finder, you'll see this .lock file isn't the same as the actual catalog.

[Chris Kern]

Check when running in Finder, you'll see this .lock file isn't the same as the actual catalog.

Understood.  It's a separate file from the actual database (catalog) file, spawned by the Lightroom top-level process on invocation, that prevents another coactive instance of Lightroom from modifying the catalog.  (Many UNIX programs use this admittedly-simple but effective file-locking technique.)  My question is whether when the catalog is locked—in other words, while Lightroom is executing—is the catalog guaranteed to be kept in a consistent state—for example, by flushing database changes as soon as they are made or at frequent intervals (e.g., once every second).  I haven't been able to find any documentation on the Adobe website(s) that describes what measures an executing LR process takes to preserve the integrity of its catalog.  And the option to "optimize" the catalog when saving it made me wary about not using LR's built-in catalog back-up scheme.

[kers]

I have catalogs going back four versions!!  Never felt the need to delete them and one never knows in this day and age when they might be needed.   

Lightroom 6 (last version was 6.14)
Lightroom 6.14 itself is 64-bit, but the installer and licensing code are 32-bit. If it’s already installed, Lightroom 6.14 may continue to work, but you won’t be able to install, uninstall or reactivate it. For these reasons, Adobe does not recommend using it on Catalina and it is not supported on Catalina.

So this might complicated things also when going back...

[JRSmit]

Understood.  It's a separate file from the actual database (catalog) file, spawned by the Lightroom top-level process on invocation, that prevents another coactive instance of Lightroom from modifying the catalog.  (Many UNIX programs use this admittedly-simple but effective file-locking technique.)  My question is whether when the catalog is locked—in other words, while Lightroom is executing—is the catalog guaranteed to be kept in a consistent state—for example, by flushing database changes as soon as they are made or at frequent intervals (e.g., once every second).  I haven't been able to find any documentation on the Adobe website(s) that describes what measures an executing LR process takes to preserve the integrity of its catalog.  And the option to "optimize" the catalog when saving it made me wary about not using LR's built-in catalog back-up scheme.

I do not use the LR backup, but do a backup on system level after closing LR, typically end of working day.
This backup does backup a lot more, also the image files and any LR related files. Of course also stuff like icc profile and printer related system files. I am on Windows10, and use 2BrightSparks applicaties for backup.

[ericbowles]

One  advantage to the Lightroom Backup on exit is that it runs an integrity check on your LR catalog and files and repairs files that have been corrupted.  It is possible to have corruption so that backing up outside LR simply maintains corrupt data.

[DP]

It is possible to have corruption so that backing up outside LR simply maintains corrupt data.

and why 'd one use a backup solution that does not support an unlimited versioning for example ? if somebody is that stupid then the punishment is well deserved