Skip navigation
mark8976
Currently Being Moderated

Lightroom encountered an error when reading it's preview cache

Aug 1, 2011 12:07 PM

I been getting this error for over 2-3 months and thought it would go away with the new version releases, i tried all the standard fixes,deleting the catalog,compacting etc. even moving it to new folder, reinstalled the software twice.  The whole nine yards. IMHO, there's a problem with the software, it may be uique with differetent type of machine setup or a corrupt file in the in the catalog and the compacting doesn't fix it.

 

The error always happens while in the develope and crashed, has to leave the software (sometimes it just hangs the software and you have to kill the task manually).  You have at least 10-15 seconds before going back in, otherwise it will still crash, a thread is still occuring from the orginal crash and still completing it's task. That's the error, annoying as heck.

 

My only hoping is a new version of LR comes out soon (4.0) and it goes away, otherwise, I'm going to find something else-- driving me crazy, I spend about 10-15% of my time each week getting out and back in to make go away, then can go for a day(s) sometimes and no problems.  I tried recreating the problem on specific photos where I think it might be corrupt, that doesn't give any clue, there is no pattern to this at all, it happens randomly on new photos and old photos, yet i can go back to those photos again and no problems.

 

Any NEW ideas would be appreciated (no compact, no new catalogs, new installs, turn off various options cache preview etc. move to new folder and more.....done that etc.).

 
Replies
  • Currently Being Moderated
    Aug 1, 2011 12:19 PM   in reply to mark8976

    Platform details?

     

    Depending on the platform, the crash detals will be more or less available to determine where it is failing. This is probably what it is doing when you try to restart it -- writing out the crash log details.

     

    Have you blown away the raw cache completely? This is relatively static (basically read-only), and a corruption there will never be addressed by any of the normal activities you mention.

     
    |
    Mark as:
  • Currently Being Moderated
    Aug 1, 2011 3:34 PM   in reply to mark8976

    Who told you to delete the catalog? Do not delete the lrcat file, this is where LR stores everything. Reinstalling of the application will also solve nothing. Deleting preference files solves some problems but not related to either previews or cache matters.

    If you are having problems with the previews you can delete those as LR will just recreate them. The RAW cache is entirely different thing and nothing to do with the preview files. You set its size and location in preference, file handling. The Raw cache is used in the develop mode only. If it is the Raw cache causing problems, set it to a larger size and on a drive separate from where the catalog is located. Constant problems may indicate a hard drive failure..

    Corrupt files and folders are usually down to hardware problems. Try your catalog on a different hard drive as the major problem is with hard drive failures.

     
    |
    Mark as:
  • Currently Being Moderated
    Aug 1, 2011 5:02 PM   in reply to mark8976

    The things you are doing with the catalogues sound dangerous, and are probably unrelated to the problem at hand. Those folders of previews /are/ the catalogue. They are the on-disk expression of the preview database.

     

    What is the exact error you are getting?

     

    The .lrcat file is the image database -- this is where all your changes to images are stored. It is unlikely any complaint about previews is related to this file structure.

     

    The .lrdata file with the same name is the image previews used throughout Lr. It is a disk-based indexed database.

     

    The raw cache is a different beast altogether, and I only mentioned it because you said you ran into problems in the development module only, and this cache is used only for that. Mostly, it is a data point. However, the raw cache can be recreated at will with no ill effects (other than slower image load times the first time opening in development.)

     

    As suggested elsethread, much of what you describe doing is probably unrelated at best, and dangerously cavalier with your data at worst. At least, from your description, anyway. I know you are getting tired of this, but hand-waving and referring to generic "caches" and "files" and not being specific is not going to garner much sympathy. Be specific because otherwise we are just guessing. Words like database, catalogues, previews and caches mean something very specific in this application domain.

     

    Start from the error message details and any real hard information you can gather and work from there.

     

    For example, you stress that you have the same problem in backed up catalogues. This suggests the problem probably has nothing to do with the catalogues, specifically. Something goes wrong at some point, so all previous backups become bad? Possible, but unlikely. Unless you can prove all those backups were taken after the problem manifests.

     

    You also mention that you see the problem on two different sets of hardware. This is a good data point, but it is worth asking, did you clone the systems (either with some third-party tool or with the Windows Vista "move my system to a new box") from one to the next? This could have migrated the problem to the newer box.

     

    But any of this stuff can be considered and discounted until we find the problem. Unfortunately, we don't know what you have and have not done, and there are key details you have hand-waved over in these descriptions. Which is why I suggest taking a deep breath and working with the folks here to solve this.

     

    Unless you are blowing off steam before abandoning the issue, in which case I guess there isn't much we can do.

     
    |
    Mark as:
  • Currently Being Moderated
    Aug 1, 2011 6:09 PM   in reply to mark8976

    Ok, fair enough.

     

    So, let's recap:

     

    This error is related to the previews only. Even backup .lrcat catalogues will use the latest previews (as they are not backed up.) So the .lrcat file is unrelated.

     

    This implies that the .lrdata directory has a faulty index or .lrprev file in it. But, here's the catch: it has to be the /related/ previews folder/database. That is, double-check that the preview folder in question has the exact same name as the basename of the .lrcat file you know you have open when you get the error, and it is in the same directory. (I'm pretty sure there is no reference to this in the preference file.)

     

    Assuming this all checks out, my understanding is that you removed or renamed the entire .lrdata folder and restarted Lr (please confirm this.) Is the problem fixed for a short time and then reoccurs? Or is the problem immediately persistent even if the previews DB is removed and recreated?

     

    If we know that the right folder is being deleted, and the problem persists, we have to look outside of the application for possible issues. Typically, this is hardware, though you assert that two different installs on different hardware exhibit the same symptoms. Given this, I still wonder if there is some Windows service that is causing a problem. Do both systems have the same real-time anti-virus protection? If so, I strongly suggest you configure it to ignore Lightroom activity. All it will do is slow things down, and /possibly/ cause data commit  and timing errors.

     

    Likewise, do you have any automated disk clone service that makes series of online backups? This Windows service (unlike a hardlink backup to another device) can interfere with file locking and atomic IO, leading to all sorts of hard-to-diagnose hilarity.

     

    The problem with either of these scenarios is that everything else can appear to be working fine except for one app. It is all about the timing and the order of system calls.

     

    Let's start with that and see where it gets us.

     
    |
    Mark as:
  • Currently Being Moderated
    Aug 2, 2011 8:12 AM   in reply to mark8976

    mark8976 wrote:

     

    Can elaborate (or give an example what your folder is setup like) what you mean by:  double-check that the preview folder in question has the exact same name as the basename of the .lrcat file.

     

     

    clvrmnky@thor:~ $ ls -l  ~/Pictures/Lightroom/

    total 367776

    [...]

    drwxr-xr-x  20 clvrmnky  clvrmnky        680  1 Aug 21:16 Lightroom 3 Catalog Previews.lrdata

    -rw-r--r--   1 clvrmnky  clvrmnky  188284928  1 Aug 21:17 Lightroom 3 Catalog.lrcat

    [...]

    clvrmnky@thor:~ $

     

     

    Note that the .lrcat and .lrdata filespecs have the nearly the exact same basename, differing only in " Previews". You can have multiple catalogues in the same folder, so it follows you can have multiple related preview databases, too. They share a common basename pattern.

     

    I do have Norton Internet Security running on both machines(however, it runs only when the computer is idle in the background, it's a lot better then the old days, no detected slowness), i can disable that for a while and see it what happens.

     

    I would advise making sure that this service /never/ looks at Lr activity. I have first-hand experience as a maintenance coder how these services can introduce all sorts of subtle problems. Think of it this way: these services insert themselves as blobs of .sys files into many system calls. These system calls are used to read/write files in an atomic and safe manner. Every real-time AV system out there I have looked at can introduce subtle corruptions where the application that made the system call has no idea anything went wrong.

     

    This is not about CPU cycles. It is about file IO corruption, and every real-time AV systems can interfere with some app out there. Be aware that no real-time AV system uses blessed and approved operating system methods of doing what it does; this means than every one of them uses a series of hacks and tweaks to get what it wants. Sometimes this is ok, and other times it leads to hard to diagnose and subtle file and (sometimes) memory corruptions.

     

    I'd bet a baker's dozen of your favourite doughnuts this is the source of the problem.

     

    1. Shut down Lr. Let it exit completely.

    2. Rename or delete the previews database (the /correct/ top-level .lrdata folder, as described above and else-thread.) The entire folder is the previews, so don't just assume you can delete the indexed folders it contains, or the two SQLite database files in the .lrdata folder.

    3. Tell any real-time AV systems to completely ignore Lr app activity against any file it wants to access. We don't want any database commits to be improperly flushed and resulting errors suppressed. There is no way around this. If you want this to be an accurate test, you must disable the service completely, or tell it to ignore all memory and file IO by Lightroom.

    4. Restart Lr.

     

    You can rebuild all previews, or you can let Lr do it on an as-needed basis. Maybe work with a subset of your images heavily for a day so that those previews are constantly updated. See if you can reproduce the issue.

     

    Note that the .lrdata folder structure will contain many empty directories. This is normal, expected and actually required for timely database activities.

     
    |
    Mark as:
  • Currently Being Moderated
    Aug 7, 2011 11:31 AM   in reply to clvrmnky

    I just created a brand new catalog imported my pictures. Edited over 25 pictures

    when I tried to edit another image the image was black

    you know the image was there but it didn't show when you hit the develop button. I decided to close it and reopen it and it wouldn't shut down.

    Computer froze when trying to shut it off so I had to turn the computer off with the button. This is a MAC when I tried to reopen LR I got this error. My other files open but when I try to open this one I get the same error. I really don't want to have to create a new folder because I spent a lot of time editing all these images. What's next. How do you get support for this issue from LR.

     
    |
    Mark as:
  • Currently Being Moderated
    Aug 7, 2011 1:09 PM   in reply to Linda Constant

    Linda Constant wrote:

     

    I just created a brand new catalog imported my pictures. Edited over 25 pictures

    when I tried to edit another image the image was black

    you know the image was there but it didn't show when you hit the develop button. I decided to close it and reopen it and it wouldn't shut down.

    Computer froze when trying to shut it off so I had to turn the computer off with the button. This is a MAC when I tried to reopen LR I got this error. My other files open but when I try to open this one I get the same error. I really don't want to have to create a new folder because I spent a lot of time editing all these images. What's next. How do you get support for this issue from LR.

     

    (By the way, it's "Mac", not "MAC". It isn't an acronym, as MAC is acronym for something else.)

     

    Almost certainly your problem is unrelated to most of what is going on in this thread. In your case it sounds like a hardware fault, probably a failing disk. My guess: at some point a critical, atomic flush to disk, probably of an updated preview, failed. Lr needed to make sure that the write was successful, so it awaited confirmation from the OS. When you killed the app it left the preview cache in an odd state.

     

    I'd make sure I verified that the disk on which this resides is healthy. Remember that hard drives fail all the time, and laptop drives fail more often than desktop drives.

     

    But, you can probably get around the preview error by recreating the previews cache. This is done by removing or renaming the .lrdata folder (NOT the .lrcat file!) that is related to your catalogue and restarting Lr. See my description of how the catalogue and previews database file/folder names are related in an earlier comment. Note that recreating the previews does not reverse any changes you have made to the referenced image files. Those changes are stored in the Lightroom catalogue. Previews are refreshed based on the queued changes in the catalogue.

     

    First access of referenced image files will be a little slower while it builds the previews.

     

    Note that if your disk is starting to fail, forcing it to rebuild a bunch of previews may just force the same problem again.  So, you really need to make sure the hardware is sound. If you have more than one drive installed, or can use an external drive (with the caveat that most USB drives are terribly slow for using with Lr) you can side-step any problems you may be having with the current disk by using one of those.

     

    Also, you should probably make sure you have sound and up-to-date backups.

     
    |
    Mark as:

More Like This

  • Retrieving data ...

Bookmarked By (0)

Answers + Points = Status

  • 10 points awarded for Correct Answers
  • 5 points awarded for Helpful Answers
  • 10,000+ points
  • 1,001-10,000 points
  • 501-1,000 points
  • 5-500 points