メインコンテンツへスキップ

⚠️ Please note that this topic or post has been archived. The information contained here may no longer be accurate or up-to-date. ⚠️

Why Does C1 12 (and 20) Re-index so much?

Cputeq
This is a bit embarrassing (since I'm a database admin / developer), but I'll ask anyway.

I am wondering why capture one 12 (and now 20) re-indexes my catalog so often? I wonder if it's how I'm using the program, etc.

Right now I use a single catalog with about 9800 images. It seems whenever I import a dozen or so photos (or maybe remove them from the catalog) eventually C1 will re-index the entire catalog over again (counting keywords, tags, everything).

Is there a way to slow the frequency of these index rebuilds? Luckily I run SSDs for all my drives, but it still seems excessive. Thank you! (I have tried Googling but cannot find anything about this).

This happens regardless if I choose to "optimize the catalog" each week, etc.
1

コメント

13件のコメント

日付 投票
  • Paul Steunebrink
    How do you notice the re-indexing?
    0
  • Samoreen
    I have also noticed similar behavior when (re)enabling some filters, especially the "Adjusted" filter. Let's take an example :

    1. Let's assume that the Adjusted filter is disabled.
    2. I select the All images collection. Nothing special happens. All thumbnails are displayed quickly as I'm browsing through the images.
    3. I select a folder and I activate the Adjusted filter. The number of adjusted images in that folder is displayed instantaneously.
    4. I select other folders. Same behavior.
    5. I select the All images collection again. C1 starts scanning everything in the catalog (Paul, just looking at the counter at the top of the image browser window is enough).
    6. In order to stop the scan, I disable the Adjusted filter.
    7. If I select a folder that I have already selected in steps #3 or #4, it scans it again.
    8. If I select again the All images collection, C1 starts again to scan the whole catalog, although I did absolutely nothing else than the steps described above.

    Obviously, C1 is looking again for information that should already have been stored in the catalog. It seems that some user actions are triggering a full rebuild of the database. As I explained elsewhere, the mere comparison of the database structure of C1 with Lightroom shows that this structure is rather simplistic. It seems that the C1 catalog doesn't store enough information to be able to react as fast as possible to user requests in some cases.

    While I'm writing this, after executing the steps above, C1 is blithely scanning again all the image folders I have imported into the catalog. And this will take a while, I'm afraid...
    0
  • Samoreen
    Paul_Steunebrink wrote:
    How do you notice the re-indexing?

    Paul,

    Beside the answer I gave above, a good way to observe what C1 is doing is to use a process monitor and trace i/o operations (at least under Windows). So, currently, I can see that C1 is reviewing again each and every file in all imported folders although there's absolutely no reason for it to do so. I can also observe that C1 is (re)building the previews for all images although this is unnecessary. It should only rebuild the previews on demand for the images that are in view in the image browser.

    I have also noticed that C1 might crash after starting such unnecessary operations. As C1 is currently re-scanning all my images, I suspect that the operation will not terminate gracefully. It takes too much time and C1 is gradually consuming more and more memory in my system... All physical memory is now almost exhausted, so I'll put an end to this game now.

    So I agree with CpuTeq : the catalog operations are flawed. C1 is doing much more work than it should.
    0
  • Samoreen
    Samoreen wrote:
    All physical memory is now almost exhausted, so I'll put an end to this game now.


    I have stopped the i/o operations by selecting another collection but the used memory has not been recovered. I'll have to exit C1.
    0
  • Paul Steunebrink
    Samoreen wrote:
    Paul_Steunebrink wrote:
    How do you notice the re-indexing?

    Paul,

    Beside the answer I gave above, a good way to observe what C1 is doing is to use a process monitor and trace i/o operations (at least under Windows).

    ...

    All physical memory is now almost exhausted, so I'll put an end to this game now.

    So I agree with CpuTeq : the catalog operations are flawed. C1 is doing much more work than it should.

    Thank you for your explanation.
    0
  • Cputeq
    Paul_Steunebrink wrote:
    How do you notice the re-indexing?


    This behavior is noticeable when on the Library screen.

    I haven't not logged the actions to trigger this behavior as well as Samoreen , but say for instance I highlight the "All Images" under "Catalog Collections" (it's my only collection).

    I have a small browser bar on the right of the screen, but it's displaying previews that were built long ago.

    Under "Filters", I have (expanded) Rating, Color Tag, Keywords sub-sections.

    I will do some operations (nothing too major) and when I return to "All Images" under the collection, I will see the counts besides the filter sub-sections increment from 1 all the way up to XXXX (whatever my final image count is), as C1 is rebuilding the index of 1-star, 2-star, 3-star, none-color, red-color, and keyword photos, etc (so the counts of the various sections increments...quickly, but it still takes a bit).

    This is noticeable because the rebuild takes almost a minute with my SSD and my hard drive usage spikes and C1's responsiveness goes down -- If this were an index scan, it (should) be much faster but it appears to be rebuilding the index, not scanning it.

    I thought perhaps the index pages were getting too out of whack for C1 to handle (fragmentation), hence the rebuilds, but sometimes these rebuilds happen after just a few image operations (again, Samoreen seems to have documented this more).

    I understand index rebuilds are required sometimes, but these rebuilds seem to be very aggressive in nature with a very low tolerance for fragmentation. I realize the index (or indices) may be holding much more data than a typical database index will (depending on how they're structured), but especially for something like an SSD installation, fragmentation is much less of an issue -- so the index rebuilds are actually slowing C1 down more than a fragmented index would.
    0
  • SFA
    I think If C1 catalogues had a fully self contained database that was not accessible in any way other than through the database functionality the needs for re-assessing counts per index would indeed be minimal.

    But if one considers the potential for direct access to the image folders and especially the use of referenced image (and therefore referenced folders) as well as the potential for folder sharing with C1's traditional Sessions functionality the concept of and entirely 'closed and secure' database just does not apply. Whether the controls are potentially breeched by one file or many makes no difference.

    In much the same way there are potential issues about files being present in the folder and the DB but modified by external applications and, of course, external management of metadata. Or being removed from the system by external applications.

    For sessions this is simply something that is best checked when opening the session.

    One could argue that for catalogues the management should be more self contained and indeed that is true up to a point in that the catalogue knows what it has and contains the thumbnails and previews that allow it to function somewhat even if the original source image has gone missing. But since it has been deemed necessary to check in advance whether the source image has gone missing in order to pre-advise the user of the loss there seems to be no good reason not to check for other changes as well. I cannot imagine that users would accept it working any other way - UNLESS they accepted that the entire system was to be totally self contained and self managing. In other words all images had to be managed (not referenced) and all externally created or modified images and any metadata had to be managed in and out of the database at the time of creation rather than having the ability to check for files in referenced folders.

    Alternatively one simply does not attempt to check the validity of the count numbers or the index until the user starts a task to do so. That would be another approach to the problem that some might accept but I suspect the majority of users would not.

    Just my thoughts - and part of the reason I mostly use sessions for everyday editing work.

    Grant
    0
  • Samoreen
    Grant,

    I understand your explanations but what you say has always been true. However, this unbridled disk activity appears to be specific to versions 12 and 20. I did use version 12 for a very short time. Thus, one can consider that I directly jumped from version 11 to version 20. But I have never noticed these problems before. This appears to be a new behavior.
    0
  • SFA
    Samoreen wrote:
    Grant,

    I understand your explanations but what you say has always been true. However, this unbridled disk activity appears to be specific to versions 12 and 20. I did use version 12 for a very short time. Thus, one can consider that I directly jumped from version 11 to version 20. But I have never noticed these problems before. This appears to be a new behavior.


    Maybe it's a very specific catalog thing for some reason.

    Using mostly sessions (or relatively small test catalogs) I have not noticed anything different.

    I will admit I have not specifically looked for any differences but then nothing seemed to be different in a way that attracted my attention.

    Perhaps something will make itself obvious when I am forced to switch to Windows 10?


    Grant
    0
  • Dave R
    SFA wrote:
    Samoreen wrote:
    Grant,

    I understand your explanations but what you say has always been true. However, this unbridled disk activity appears to be specific to versions 12 and 20. I did use version 12 for a very short time. Thus, one can consider that I directly jumped from version 11 to version 20. But I have never noticed these problems before. This appears to be a new behavior.


    Maybe it's a very specific catalog thing for some reason.

    Using mostly sessions (or relatively small test catalogs) I have not noticed anything different.

    I will admit I have not specifically looked for any differences but then nothing seemed to be different in a way that attracted my attention.

    Perhaps something will make itself obvious when I am forced to switch to Windows 10?


    Grant

    Merry Xmas Grant,
    To see all the catalogue problems described in various threads you do need a large catalogue at least 20000+ images, preferably more. I have a feeling that the Capture One technical team use small datasets for testing and miss some of the problems evidenced in large data sets.
    I have more or less given up on the catalogue function in Capture One and gone back to using Lightroom for cataloging and Capture One in session mode navigating to the picture I want to edit rather than using the session specific folders.
    Dave
    0
  • Permanently deleted user
    Basically this is the same issue that the sessions are having - they don't "remember" the files, and have to re-index everything everytime.
    On a fast drive that's okay but only if there are no more than a few hundred files. With +1000 is still takes a long time to open a session on a SSD.

    So no, it's not catalog specific. It's just bad programming by C1.
    0
  • Sébastien Gobeaux

    What I don't get it, is why this is not a top priority ?

     

    Me too, I had to switch back to LR.

    1
  • Permanently deleted user

    I think it would require to completely overhaul the file handling structure of the program. And that's a lot of work. And that's why they're not doing it.
    This has been an issue for years, I remember discussing this 3-4 years ago....

    0

投稿コメントは受け付けていません。