Luminous Landscape Forum
Raw & Post Processing, Printing => Adobe Lightroom Q&A => Topic started by: john beardsworth on November 04, 2019, 02:33:44 pm
-
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
-
And a new splash screen; that's HUGE ;D
But a few more useful items outlined here:
https://www.lightroomqueen.com/whats-new-in-lightroom-classic-9-0/
-
wow what a das Update. Once again no psb support or larger files.
-
I wonder why we still don't have .heic as an export filetype option. The quality and/or storage improvements sound substantial.
-
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?
-
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.
-
No, but that's no reason NOT to backup the previous catalog and keep it around awhile.
Of course. Goes without saying.
-
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.
-
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. ;D
-
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?
-
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.
-
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?
-
Locked catalog?
-
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
-
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.
-
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 (https://helpx.adobe.com/lightroom-classic/kb/lightroom-error-catalog-cannot-be-opened-lrcat-lock.html). (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 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. ;D
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...
-
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 (https://helpx.adobe.com/lightroom-classic/kb/lightroom-error-catalog-cannot-be-opened-lrcat-lock.html). (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.
-
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.
-
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 ;D
-
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.
Well if your lr is corrupt at that point and you do not do the lr backup, then what?
Have you experienced a corrupt lr?
-
and why 'd one use a backup solution that does not support an unlimited versioning for example ?
Or a data integrity check. Or just multiple backups. Yeah, the backup LR does checks just the catalog. There's a whole lot of other data that needs to be checked prior and after said backup (like your images).
Whatever the opposite of a belt and suspenders approach to back up is, that's the LR backup schema. It's better than no back up of course, but it's not a serious and robust backup schema either.
-
As a former database administrator, I’d say it’s likely that the LR Catalog cannot be guaranteed to be internally consistent while LR is running. Even though you might not be actively doing anything, LR does all kinds of housekeeping while it is running.
-
As a former database administrator, I’d say it’s likely that the LR Catalog cannot be guaranteed to be internally consistent while LR is running. Even though you might not be actively doing anything, LR does all kinds of housekeeping while it is running.
Do you know that to be true, or are you extrapolating from your experience with other databases and assuming it to be so?
Jeremy
-
Do you know that to be true, or are you extrapolating from your experience with other databases and assuming it to be so?
Jeremy
I'm certainly no expert on the matter, though, I do recall reading comments discussing just those points many years ago in the early days of Lightroom on both the public beta forum at Adobe Labs and on the Adobe U2U forum about background tasks of the internal database while the app is open. I think such traits are inherit of SQL based variants.
In fact, when Adobe first offered a backup function for the Lightroom library file, the task had to be accomplished on startup to assure all background functions had yet to be invoked at startup ... it wasn't until later, after much more effort, that the backups could be performed upon quitting the app.
-
I haven’t examined the LR code, no. However, I’ve observed enough industrial-class databases to know that there’s no such thing as guaranteed consistency when an unexpected failure occurs during updates. Pretty much every update requires many individual records to to be written, which “two phase commits” protect against. Yet sometimes they don’t, and the recovery is painful.
-
Hi,
I am finding some of the terms used beyond my technical vocabulary. I use the Lightroom backup on exit to deal with the catalogue. I also have LR set to put the xmp files alongside my images on my internal hard drive. That hard drive is backed up on to 2 external hard drives so I am backing up the images, xmps and catalogue.
Should I being doing anything else?
Best wishes,
Jonathan
-
Should I being doing anything else?
It sounds like you're now doing this; cloning the entire drives and all their contents but otherwise, you should be backing up all and any data you can't afford to lose, ideally to multiple devices, at least one off site. So that means all your images, your presets, templates, your camera profiles, etc. On top of all the other non LR specific data you never wish to lose.
One could argue you don't need to backup the image previews; you can always regenerate them and they take up a lot of space. But that takes a lot of time so it's a judgement call (again, can you afford to lose the previews? Maybe).
-
Thanks Andrew. I am happy as all my images are backed up on more than one external HD, together with the xmps. My catalogue is backed up on more than one HD as well. I only have a few print presets. so not worried about them. The paper profiles are backed up.
I will probably upgrade LR classic to 9 in the new year.
Best wishes,
Jonathan
-
The paper profiles are backed up.
FWIW, I was referring to any custom camera profiles you may use.
-
Andrew, I shoot with Fuji and Canon cameras and lenses and have no custom camera profiles. Thanks for your advice.
Best wishes,
Jonathan