Database verification fails
The database verification when backing up a catalog passes, but the more robust verification when the catalog is not loaded often fails at this point, even though the catalog shows no problems:
Checking for catalog folder collections without a project FAILED!
The use of the term "folder" should refer to folders in Finder containing referenced files. These folders do not contain anything but subfolders and files. Similarly, referenced files do not need to be referenced by a project. They can be referenced by an album.
If I let Capture One repair the catalog, the verification passes, but days later, the same error occurs. I am not sure if this is related or unrelated to importing new RAW files.
So, what is the message telling me and how would one review projects in a catalog folder collection? Why does it keep appearing even after the catalog is repaired, and why does it not seem related to any problem?
-
Mac or Windows? What version of C1 and the computer OS?
Do you happen to be deleting image files between verifications? I'm working with 2 referenced catalogs. I verify the database when I close the catalogs to be sure that all's OK. I've verified that "repaired" catalogs open properly and close again without errors if I do nothing in them.
I can work with either catalog as much as I want in terms of importing files, adding/modifying metadata, making adjustments, exporting, etc. and upon closing the catalog, verification always passes.
BUT almost every time I delete one or more image files and empty C1's Trash, I get the same verification.error, which is always related to locating files. I'm on Macs, and I assume this has to do with Capture One lacking somewhere in its macOS integration (I'm using C1 16.3.8.23 on MacOS Ventura). I don't recall this happening with 16.2 and earlier. Or else C1 isn't properly updating its internal pointers to images on the disk.
Since the problem happens under reproducible conditions on 2 M2 Macs and hasn't caused any issues that I can see, I just ignore it (although it does concern me).
I should note that the catalogs were initially created in earlier versions and then updated with v16.3.0. Also, the problem happens even when I've had C1 relocate all originals and rebuild all previews, so I assume the program knows where all image files are.
You could try opening a support case and hope for a resolution. IF you do get definitive help, please post back to this thread.
0 -
I am on an M2 Mac Studio Ultra with Sonoma 14.6 and Capture One 16.3.8.23. I see the same issues with the same OS and and Capture One version on my Intel MacBook Pro. Like you, I have no problems with verifying when I close the catalog. My workflow is much like yours. After importing into an album, I delete unwanted imports. After editing, I use Capture One to relocate the imported keeper image files to a reference file location. I then delete the unwanted imports and empty the trash and close the catalog after backing up and verifying.
My catalog was originally created with Capture One version 8. The problem is not device dependent -- happens on both computers. It does not cause any detectable problems. All of this has me curious about exactly what it means by the murky message, Checking for catalog folder collections without a project FAILED.
Perhaps worth submitting to support. At minimum, they could explain the meaning of the message.
0 -
Your workflow sounds exactly like mine, only I haven't upgraded to Sonoma because I'm worried about Capture One (good to know that it's working for you).
Like you, my main catalog was originally created with v8. Your error's a little different than mine, as it has to do with collections, whereas mine has to do with file locations. Both problems, though, have to do with Capture One's database (which I've seen has a bunch of reported issues and requests for improvements).
Yes, might as well submit a support request, although we're both on down-rev versions, so a request may not be answered. Please post to this thread if you learn anything.
One thing: at one point I created a new catalog with 16,3, used it with several thousand images from a wildlife outing, and had the same problem, so I doubt that it's related to having updated an older catalog.
0 -
Give this a try. Create a new catalog and import into it the catalog that is failing to verify. Then see if the new catalog verifies. A few times in the past I've had a catalog that had issues where starting clean and importing the old catalog fixed it. If this fails to remedy the problem then definitely open a support ticket.
If the catalog import succeeds it will NOT have any previews so it will have to render them all again. Check the All Images count from both old and new catalogs to make sure they are the same.
0 -
Perhaps this may mean something (from a previous post):
After installing version 16.1, half of one folder's* subfolders displayed the message, "No Images in Collection" instead of displaying the thumbnails of files in those subfolders. Clicking on the corresponding albums in the library showed the corresponding thumbnails and they could be located in Finder. Moving some new files from a catalog album to an affected subfolder resulted in them being moved to that subfolder on the hard drive, but the subfolder count was not updated. No other folders were affected.
The problem seems unrelated to version 16.1 and is related to a catalog database. The same issue was present in the backup copy I made before upgrading the previews. When the database is backed up, the Test Integrity process is not comprehensive. When I ran the Verify Catalog it failed a full verification check, showing: "Checking for catalog folder collections without a project FAILED! Database content error."
I then ran Repair, which fixed the problem. It is tempting to think the problem was related to the message, but there could have been other failures that occurred, that were not shown because the listing stops with the first failure.
This is sounding mostly like parts of the database can lose the location of files in a referenced file folder if it cannot relate it to a project in the library.
0 -
Walter—you may be on to something. I just did as you suggested, importing my catalog into a new empty one and regenerating all previews. The new catalog verifies correctly, and two other things happened:
1. When parsing the old catalog, Capture One discovered that 2 original Raw images (out of >55,000) were missing. Sure enough, the old catalog had continued to think they were present although they'd been deleted more than a year ago.
2. The new catalog, with previews, is 25 GB smaller than the old one. This really surprised me, as I'd had C1 16.3 regenerate all previews a while back. I know that previews take up space, but that much? Is Capture One storing not only the original preview, but also all of the higher-res previews created when editing an image at 100% magnification? And if the latter, will regenerating previews bring the catalog size down again?
The growth in catalog/preview size is surprising. I tend to generally not revisit images after editing and printing or sending to clients. It would be nice if users had some visibility into what's happening with previews and maybe have a button or preference setting to purge unneeded previews.
Anyway, I'm working in the new catalog now and will see whether it gives verification errors after my next couple of big cull/edit sessions.
0 -
I've had other mysterious things clear up by doing this. Glad it helped.
0 -
Inside the catalog package you can look at the Cache folder size of the old and new catalogs. Assuming all previews have been generated in the new catalog that comparison will tell you if previews and thumbnails represent the difference.
0 -
Yes, deleting an image or two, then emptying the C1 trashcan does create a database corruption error. That doesn't instill too much confidence in me. I would like the database to be absolutely solid. Come on, C1, get it together.
0 -
Interesting observation: I finally did as Walter suggested. Corruption problems gone (so far) BUT (there's always got to be a 'but', right?): after importing the old [referenced] catalog into a new empty one, C1 found 2 files that the original catalog thought it had, but turned out not to be on disk. These were files I'd deleted a couple of years ago. Note that the original catalog had been "successfully repaired", therefore I don't understand how that obvious error got maintained through multiple "repairs".
Yes, the error described above was 100% reproducible in my original catalog (which I. no longer have), and hasn't happened (yet) with the new catalog. How does one file a bug report on something like that? Reproducible, but can't provide any data at this point other than the original symptoms?
0
Please sign in to leave a comment.
Comments
10 comments