Zum Hauptinhalt gehen

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

(Very) slow start up time

Kommentare

55 Kommentare

  • Willi B

    I have the same problem, plus the fact that making adjustment to the pictures is very slow. I proceded the same way you did, but the problem isn't solved. I think the problem doesn't come from the computer, since CO22 is still functioning very well.

    0
  • PataFP

    Update: I was looking through the logs (ImgCore log) and theese ones got my attention:

    2022-11-15 12:01:58.399> (ERROR) bin file failed parse [C:\Users\pabli\AppData\Local\CaptureOne\ImageCore\16.0.0.143\ICOCL1.bin] (verificationCode=7)
    2022-11-15 12:01:58.883> First chance exception (thread 14568): 0xE06D7363 - C++ exception
    2022-11-15 12:02:00.228> First chance exception (thread 8960): 0x406D1388 - Set thread name
    2022-11-15 12:02:00.228> First chance exception (thread 884): 0x406D1388 - Set thread name
    2022-11-15 12:02:00.228> First chance exception (thread 7944): 0x406D1388 - Set thread name
    2022-11-15 12:02:00.244> First chance exception (thread 11640): 0x406D1388 - Set thread name
    2022-11-15 12:02:00.244> First chance exception (thread 9300): 0x406D1388 - Set thread name
    2022-11-15 12:02:00.244> First chance exception (thread 13596): 0x406D1388 - Set thread name
    2022-11-15 12:02:00.244> First chance exception (thread 5784): 0x406D1388 - Set thread name
    2022-11-15 12:02:00.260> First chance exception (thread 10928): 0x406D1388 - Set thread name
    2022-11-15 12:02:00.260> First chance exception (thread 7000): 0x406D1388 - Set thread name
    2022-11-15 12:02:00.260> First chance exception (thread 16112): 0x406D1388 - Set thread name
    2022-11-15 12:02:18.748> First chance exception (thread 3664): 0xE06D7363 - C++ exception
    2022-11-15 12:02:18.748> (5 identical messages logged; delayed 22.262s .. 22.261s.)
    2022-11-15 12:02:18.748> First chance exception (thread 13244): 0xE06D7363 - C++ exception
    2022-11-15 12:02:18.748> (5 identical messages logged; delayed 22.170s .. 22.170s.)
    2022-11-15 12:02:18.748> First chance exception (thread 3356): 0xE06D7363 - C++ exception
    2022-11-15 12:02:18.748> (29 identical messages logged; delayed 22.185s .. 22.158s.)
    2022-11-15 12:02:18.748> OpenCL CL_DEVICE_GLOBAL_MEM_CACHE_TYPE : 2
    2022-11-15 12:02:18.748> (Message delayed 21.613s to prevent duplicates.)
    2022-11-15 12:02:18.748> OpenCL CL_DEVICE_ADDRESS_BITS : 64
    2022-11-15 12:02:18.748> (Message delayed 21.613s to prevent duplicates.)
    2022-11-15 12:02:18.748> First chance exception (thread 14568): 0xE06D7363 - C++ exception
    2022-11-15 12:02:18.748> (5 identical messages logged; delayed 19.878s .. 19.878s.)
    2022-11-15 12:02:18.748> First chance exception (thread 4204): 0xE06D7363 - C++ exception
    2022-11-15 12:02:18.748> (35 identical messages logged; delayed 21.921s .. 18.836s.)
    2022-11-15 12:02:18.748> First chance exception (thread 8732): 0xE06D7363 - C++ exception
    2022-11-15 12:02:18.748> (6 identical messages logged; delayed 22.252s .. 18.508s.)
    2022-11-15 12:02:18.748> Started worker: TileExecuter 0 [PackageBitmapGPUProcessor0] (master: 1fe0, worker: 1714)
    2022-11-15 12:02:18.748> First chance exception (thread 4204): 0xE06D7363 - C++ exception
    2022-11-15 12:02:18.826> Started worker: TileExecuter 0 [PYRAMID_PackageBitmapGPUProcessor0] (master: 2e94, worker: 3270)

     

    during this time, CO23 was unresponsiveness (and it matches more or less the start up time difference between 20 and 23)

    0
  • Slovakbrit

    This as you know is the same problem I and many others had with C120 and C122, no-one has so far come up with any solution so good luck with the support team.

    0
  • PataFP

    Well, i did some test, i have around 40k pictures, made 2 catalogs with the same pictures, one with the preview size set to 2560px, and the other is set to 1920px. launched CO23 (using the same last folder open, wich had 79 photos in it). In the Application log searched the lines:

    [2022-11-16 15:06:21.549][313][ID:001,       Main]{PSIST} | Opening document : C:\Users\pabli\Pictures\Catálogo completo\Catálogo completo.cocatalogdb

    and

    [2022-11-16 15:06:48.035][095][ID:053, [Collectio]{SESPS} | Loading collection finished. Document Type: Catalog. Collection Name: '29'. Collection items count = 79. Time taken: 329 ms. 

    As you can see, it takes 26.486s to open the catalog (independet of the preview size of the pictures, varied on the order of tens of ms every time i launched CO23).

    So i wondered what would happen if i made a ~20k pictures catalog, well, that time was 13.152s (almost exactly the half!) 

    So this got me to the conclusion that it depends on the number of pictures you have in the catalog, so it will get worse everyday =(.

    0
  • Zeno Endres

    This and other alarming stories are the reason, why I will keep my CO20 Sony edition and not upgrade. The prices are one strong reason too!
    Thanks for sharing your experiences with us!

    0
  • PataFP

    Well I opened a ticket yesterday, they have responded within 30minutes, and today they asked me for the logs, so perhaps they can find out what is happening,

    0
  • Zeno Endres

    Well, i bet the result will be: your computer (some components) are to slow...!

    0
  • PataFP

    Hopefully they won't say that, besides with an i7 9700k a m2 nmve 500gb wd black and 16gb ram, CO23 is the only piece of software that lags to load (and is not the most resource demanding one)

    0
  • Zeno Endres

    Please let us know what the result of all loganalizing was...!

    0
  • PataFP

    nothing yet, i'll let you know if there is an update to the ticket.

    0
  • SFA
    Top Commenter

    If you open the Activities Window, close C1 and then open it again the Window should then show any significant activities occurring during start up. Normally that would show little or nothing as things will be fast. However, if something is running very slowly  - say the Hardware Acceleration verification and setup process - it might be displayed there.

    Usually that process only needs to run when a new version or release is installed (or some equivalent change of Hardware is identified) but if the process fails to complete fully it might end up running every time you open C1.

    In theory the system will still work and allow editing when the process is running but it may slow things down. 

    On my system (and the system before it) the check for GPU facilities found and considered the Intel software GPU included with the processor and if it decided it was worst using for Hardware acceleration purposes, would build a kernel to make use of it. For some reason this takes minutes to run and complete whereas any dedicated independent NVidia hardware GPU takes almost no time at all.

    This seems to be worse if the driver info for the GPU (Intel) has somehow become out of date.

    If the process fails it will be repeated every time C1 starts. So it's worth checking in case there is a problem.

    Apart from that, C1 starts out by loading data into the working memory area, based on what you were last working on for the Session(s)  or Catalogue(s) being opened and what was selected when C1 was closed.

    Whether you are starting from hibernation, afresh or when you run catalog backup may have some influence over  perceived startup times.

     

    There may also be some Windows Memory management activity in play if you are using multiple applications at the same time and working memory space needs to be "re-negotiated".

    0
  • PataFP

    Hi SFA, thanks for your post.

    that was my first guess, and CO team too, but it's not the problem. CO launches quickly, it takes 2secs from double clicking CO icon, to the UI to be shown. The problem comes next to that, it takes 26sec since the UI is displayed to be functional (in this time i can't even select pictures, but i can see the folder hierarchy being build), and this time it's  proportional to the amount of pictures in the catalog (if i made a catalog with half the pictures, it takes half the time). CO team told me that "Every Capture One version does check folder hierarchy at every launch, so it is likely not the case." But with CO20 didn't have this lag at start up.

    I usually close CO with a small collection selected so that it's not the case neither, it seems to do some sync every time i lauch CO as you can see in the HDD usage (where the photos are located).

    0
  • SFA
    Top Commenter

    Are you synching any external metadata?

    0
  • PataFP

    Oh, and I think that CO syncing all the files on every start up (if it does this way) is a waste of resources and time (why have a catalog file with smaller preview files if it goes and check every file during start up). It should be a selectable option instead for people who use multiple drives, or for whom use multiples software for editing or managing their photos.

    0
  • PataFP

    Sfa: no, I only use CO.

    0
  • SFA
    Top Commenter

    PataFP

    "Oh, and I think that CO syncing all the files on every start up (if it does this way) is a waste of resources and time (why have a catalog file with smaller preview files if it goes and check every file during start up). It should be a selectable option instead for people who use multiple drives, or for whom use multiples software for editing or managing their photos."

    I suppose at some point quite early in an editing session C1 needs to know if the source files are available at the current time so that it can make a decision about how to handle pre-loading previews, etc., into working memory.

    The other consideration is how well the saved preview size matches the needs of the current screen(s) and assessing the need to either scale up or scale down the preview or simply abandon the saved preview to generate a new one into working memory ready for use.

    No doubt C1 have already covered this with you.

    I work mostly with sessions and don't have any large catalogs so this is not really a matter with which I have experience.

    Also I usually hibernate rather than close, so memory load time is not much of an issue. One thing that slows the system coming out of hibernation is WiFi re-connection (generally) and especially to my NAS if I hibernated when editing a session saved on the NAS rather than an internal drive.

    Whether and how any of those factors may influence perceived load times probably needs to be investigated on a system-by-system basis. 

     

    I'm not currently using V23 but my beta testing experience suggested that general handling was, in my case, much the same to other versions using Windows 10.

    Hopefully the Support team will identify something to help you.

    0
  • PataFP

    As a workaround I made a separated catalog for each year, so now I have 10 catalogs with ~4k pictures each, this way CO loads as quickly as before, but If i want to work with pictures taked in the past years I have to change the catalog (not a big deal so far)

    As for the preview size, it didn't made difference to select 2560px or 1920px (my display resolution) in loading time, so far the only thing I have identified to lag the time to load the catalog was the amount of pictures in it (and other people reported the same in previous versions)

    0
  • PataFP

    I got an email from C0 earlier today:

    Hi Pablo,

    Thanks for your patience. After a bit of investigation, we have concluded that this is a bug. So I have filed a report with all the details for our R&D team to start working on a fix.

    So what will happen now is that I will place your ticket on-hold while we work on it.

    I will get back to you in case we need any more information regarding this report.

    We will do our very best to provide a fix for this as soon as possible, but unfortunately I can't guarantee that it will be ready for the next service release.

    I can however promise that I will keep you updated on the progress of the fix.

    0
  • Slovakbrit

    This is absolutely great news, it has been a year since I first raised a ticket regarding this issue and I am pleased that at last they have taken it seriously and are going to do something about it, well done for persevering, you are the bringer of good news to a lot of us out there, thanks and I am sure you will keep us up to date. Have a good day..... 

    0
  • Zeno Endres

    ...it has been a year since I first raised a ticket regarding this issue

    After a bit of investigation, we have concluded that this is a bug

    ..but unfortunately I can't guarantee that it will be ready for the next service release.

    I don´t know what others think about all of this but this reaction from CO tells me a lot!

    0
  • TomLondon

    It looks like you ran into the same issue as me. Maybe a bit of additional information and potential solutions from my previous post on this:

     

    Hi,

    C1 takes forever when opening. This issue exists at least since C21.. I have read https://support.captureone.com/hc/en-us/articles/360002681258-Improving-the-time-it-takes-for-Capture-One-to-open, that does not address the issue.

    When the library tab is open, it becomes clear what is the reason: It reads all directories from disk - this process seems to be really slow, not sure what it does there (approx. 1 - 2 s per line from an internal modern M2 SSD). I have deactivated the "show images in subfolders" and "hide folder hierarchy"), so it should have to do nothing but reading the directory from disk. Only after it has rebuilt the entire directory tree to whatever state it was opened to last time, it shows the last open folder. 

    This is a bit disingenuous, because in >80% of the cases I want to continue working on the last set of pictures.

    1) Would t be possible to swap the order, i.e. first display the last open folder, then build the directory tree? (or make it configurable if you really think the current order makes sense in some workflows)?
    2) It might be a good idea to check why it takes so long to show this tree - I suspect the library module does look into the folders which are not selected in some way, otherwise it seems very unlikely that it takes so long.

    0
  • Javier Sanchez Ciria

    any solution from CO team?

    I update today from CO22 to CO23 and it is imposible to work.

    Any one know how to change and come back the catalog from 23 to 22 version?

    0
  • Nikodem Binienda

    Still experiencing the same issue with CO23. Any update on the fix or workaround? This is simply not good enough.

    0
  • TomLondon

    Same here. I am using a Dell XPS with 32GB RAM, an Intel i7-1280P, an RTX2070S (eGPU) and a Samsung 990 PRO 4TB (which is less than half-full). I suppose that will be enough hardware for C1.

     

    I think the problem was addressed once and resurfaced after the next update. The symptom is simply that C1 first reads the entire catalogue tree (which takes forever, even if the "Display pictures in sub-folders is off), and only once that process is finished, it displays the current folder in the right order and allows to do any edits. It can't be that difficult to change the order of this!

    0
  • Slovakbrit

    All I can say about this is I moved backwards to Capture One 21 version 14.3.1 a year ago and I have no regrets except I paid them for two versions which are useless, I have learnt that the only people they are interested in are Apple users, despite some of us being loyal for quite a few years, we live and learn I guess, Have a good Christms everyone.

    0
  • TomLondon

    Hm. Sticking with C1-21 might be a bit of an extreme move - given recent improvements in masking, in particular. 

    For me, the load time of C1 is really annoying - but in the end, I can work around it by starting C1 before breakfast, or I do my email in the meantime. Yes, I would like this to be fixed, but it does not impact my workflow once C1 is loaded. 

    0
  • Nikodem Binienda

    So, I created a new catalogue from scratch. Loaded it with 100k photos and so far it loads very fast, less than 10 secs or so. I believe that the previous catalogue wa also created in one of the most recent versions of CO1, but I might have been wrong about that.

    0
  • PataFP

    Hi guys, sorry for not giving you updates.
    So, 2 months ago the ticket I had created more than a year ago was closed without letting me know (they didn't even sended an email, just marked it as "solved") I've noticed it because I wanted to ask them for an update and to my surprise the ticket was closed (at that time CO released the new version and there is no more development on CO23). So on November 10th I opened a new ticket citing the previous one, they responded right away saying that my system did not satisfy minimum requirements so they couldn't help me with that (i7-9700, 32gb ddr4 2666, 500gb wd black nvme +1tb wd blue ssds, amd rx6400 and w11), I emailed them back with the system requirements copied from the support page and then the same agent with whom I've interchanged a LOT of emails send me basic suggestions with no sense (and ignoring the vast information that i sended to them). I'm done trying to get support from them.

    0
  • PataFP

     

    Funny thing, the link they send me proves that there is no incompatibility in my system

    0
  • PataFP

    What's the point of having a catalog function if they suggest to load 1k images on it? It's a joke. I have around 50k images and I consider it to be a small catalog.

    0

Bitte melden Sie sich an, um einen Kommentar zu hinterlassen.