4 Messages
•
100 Points
Lightroom Classic 9.2: "Lightroom encountered problems reading or writing from disk when attempting to repair..."
LR Classic 9.2 (Build 202001311240-2d026470) on Windows 10 (up-to-date).
Steps:
1) Worked on many photos and closed LR with no issues (~400MB catalog with 60,000 photos)
2) Following day Lightroom refused to open catalog ("LR catalog cannot be opened because it is not valid")
3) Selected "Choose a different catalog", re-selected the catalog file, enabled the "Test integrity" checkbox and then [Open]
4) Message box: "The Lightroom catalog is corrupt and cannot be used or backed up until it is repaired". Clicked on [Repair Catalog]
5) After a few seconds, message box: "LR encountered problems reading or writing when attempting to repair catalog"
6) A curious message more applicable to medicine than deterministic software programming appears, something along the lines of "Keep trying, it may work next time"?!
I read several similar reports and I can safely exclude:
- Disk drive failure (no disk errors reported - moved lrcat file from HD to SSD within same machine, and on a second machine: same error)
- Disk drive lacking space (240 GB free)
- Messed up LR folder configuration
- Accidental shutdown during LR closure
- Virus or other malware
- Read/write permission issues (user account already had full control on lrcat file, folder and sub-folders, added file and folder ownership, extended Full Control to the Administrator Group, ran as Administrator, etc.)
I realize LR is quite a shaky piece of software with serious architectural issues.
I also realize that the error message about "encountering problems reading or writing" is at best a poorly designed exception handling (returning a generic R/W failure when the exception may be caused by a more specific error) and most likely hiding more serious issues when attempting to repair catalog files.
I also appreciate that I may get the quite common: "you should have an effective backup strategy in place, just use a backup catalog", but that should be neither acceptable nor ethical (for Adobe) as an answer. Yes I do have relatively recent backups and yes unexpected things can happen with computers, but the number of users complaining about weird catalog corruption cases should trigger someone high enough in Adobe to re-architect at least that portion of the product. After all, it is not free software.
I only hope that someone in Adobe can look into the lrcat file that I can make available, analyze what is corrupted, understand how it happened, and fix the corresponding code.
Thanks
Steps:
1) Worked on many photos and closed LR with no issues (~400MB catalog with 60,000 photos)
2) Following day Lightroom refused to open catalog ("LR catalog cannot be opened because it is not valid")
3) Selected "Choose a different catalog", re-selected the catalog file, enabled the "Test integrity" checkbox and then [Open]
4) Message box: "The Lightroom catalog is corrupt and cannot be used or backed up until it is repaired". Clicked on [Repair Catalog]
5) After a few seconds, message box: "LR encountered problems reading or writing when attempting to repair catalog"
6) A curious message more applicable to medicine than deterministic software programming appears, something along the lines of "Keep trying, it may work next time"?!
I read several similar reports and I can safely exclude:
- Disk drive failure (no disk errors reported - moved lrcat file from HD to SSD within same machine, and on a second machine: same error)
- Disk drive lacking space (240 GB free)
- Messed up LR folder configuration
- Accidental shutdown during LR closure
- Virus or other malware
- Read/write permission issues (user account already had full control on lrcat file, folder and sub-folders, added file and folder ownership, extended Full Control to the Administrator Group, ran as Administrator, etc.)
I realize LR is quite a shaky piece of software with serious architectural issues.
I also realize that the error message about "encountering problems reading or writing" is at best a poorly designed exception handling (returning a generic R/W failure when the exception may be caused by a more specific error) and most likely hiding more serious issues when attempting to repair catalog files.
I also appreciate that I may get the quite common: "you should have an effective backup strategy in place, just use a backup catalog", but that should be neither acceptable nor ethical (for Adobe) as an answer. Yes I do have relatively recent backups and yes unexpected things can happen with computers, but the number of users complaining about weird catalog corruption cases should trigger someone high enough in Adobe to re-architect at least that portion of the product. After all, it is not free software.
I only hope that someone in Adobe can look into the lrcat file that I can make available, analyze what is corrupted, understand how it happened, and fix the corresponding code.
Thanks
Responses
dan_hartford
474 Messages
•
12.2K Points
8 months ago
Per chance at the end of step 1, when you shut down LR, did you allow it to take a backup?
If Yes, rename your current catalog to something else (e.g. Lightroom Catalog BAD.lrcat). then unzip the backup catalog and place it in the same folder as the bad catalog. Re-try
If No, do you have other, 3rd party backup of the catalog taken after step 1 but before the failed attempt to open the catalog. If so try restoring one of those. It's a long shot as barring anything not disclosed in your post, the corruption was most likely to have occurred at shut down of LR so a backup taken later would also be corrupted. But it's worth a shot.
If no backups from that time period are available or work, Sometimes corrupted catalogs can be repaired outside of LR. I don't have the specifics, but look at www.LightroomQueen.com forums and seach for corrupt catalog for steps and if you're a member sometimes you can send the catalog to them and they can run some fix tools on it.
Other than that, I'm out of idea.
1
0
bill_3305731
431 Messages
•
5.9K Points
8 months ago
If a write to a hard drive garbles the data, there is no way to know that it happened (SMART is basically a joke) unless Adobe were to implement a read back after write and compare. This used to be an optional feature in Windows but almost nobody used it because of the performance hit. There is a simple parity written with the data but it is not ECC so that all it can do (at best) is report a hardware read error. It cannot recover from the error. This is what Lightroom is reporting to you, garbled data from the drive.
There are high integrity SSD drives available in enterprise configurations but they can't be used in a typical desktop or laptop computer due to having a different interface and costing as much as a really nice used car. And they still need at least RAID-5 for minimal data integrity.
Adobe does not need to re-architect the catalog unless we want Adobe to implement write-read-compare after all writes AND we already complain non-stop about Lightroom performance.
What can we as users do?
3
0
john_georges_jj6f12d49iwqo
4 Messages
•
100 Points
8 months ago
And no, I didn't ask for a backup at step 1 because I had one from some days ago.
Regarding HW, this happened on a 2-week old 1GB Samsung SSD which looks perfectly working otherwise and reporting no issues with CHKDSK. But I should have added that since I started using LR six months ago (on two other machines and reinstalling LR twice) this was the third corrupted catalog (same ~60,000 NEF, TIFF and JPG photos in a flat ~700 folder hierarchy). The probability that 3 cases of corrupted catalogs in 3 months on 3 different disks were all due to HW I/O is so small to be negligible. Hence my considerations.
I agree RAID-5 would mitigate potential I/O errors, but would also confirm to many that LR is a troublesome member of the software family. Imagine if in the last 35 years 1 billion MS Office users would have been told to use RAID-5 to overcome HW I/O errors when saving PPT or DOC on their PC or Mac. I don't even recall when last I had to recover a file due to HW I/O, probably decades ago. Perhaps worth noting that my first lines of code were in Assembler on an IBM PC in 1982.
One last comment: as new LR user I am surprised by the number of forum posts, sites, YouTube channels and people making a living out of teaching how to fix errors or just barely "use" LR. It is certainly powerful and comprehensive and most users would adapt to the weirdest of the UX to get things done. Regardless, shortcomings like the lack of accessibility considerations (tiny little Develop cursors anyone? or the menu chaos so 1990s and causing so many "where to find x in LR") or the poor integration with the underlying operating system, with basic file mgmt and window operations being overridden for no apparent reason and causing a UX nightmare, make me think that there may be something more than a quite unlikely HW I/O error. I may be wrong.
Cheers and again, thanks everyone.
2
0
bill_3305731
431 Messages
•
5.9K Points
8 months ago
SLED = occasional corruption
Software has no way of knowing which it is writing to.
Proof that this is a hardware problem.
That you wrote a few lines of Intel assembler does not make you a hardware expert. In fact your whole diatribe proves that you are unskilled in this area. Whereas I've been addressing hardware reliability and performance issues since 1965, have written IOS software for computers that didn't even have an operating system.
The reason that enterprise class systems have very complex and expensive RAID storage systems is just because I/O is the least reliable component of a system. It is not just the final device, HD or solid state storage, that is the problem; the whole I/O stream (including the operating system) is the cause of data corruption errors. Companies with Petabyte size storage systems get data errors on a daily basis, sometimes hundreds to thousands if they are large enough. They don't blame the software because the software CAN'T cause the problems.
Sure data corruption can be caused by software but NOT where errors are reported by the hardware when trying to read the data. A piece of software can damage the application based logical consistency of the data but this CANNOT result in a hardware error. So if the hardware is reporting that something cannot be read from a drive or array then the hardware failed when writing to the device. If the software was supposed to write XYZ and instead wrote ABC, that will not result in a hardware read error. All bit strings are completely valid to the hardware.
So can Lightroom corrupt its catalog, of course it can. But that will show up as garbled or lost information inside Lightroom, not the hardware reporting read failures. And when pressed, it will usually be found that the computer was powered off without a clean shut down of the application. It's called User Error.
2
0