C1 22 still slow loadng
I still find it very slow to load, I have a catalogue with 16,792 images and from when the programme has loaded to when the numbers of images appear is 27 secs, it was the same with C1 21, with version 13.1.4 it managed it in 11 secs and my PC goes like a train. Will someone tell me why this is so
-
Michael,
Just for clarity and completeness of discovery in searches, the hardware acceleration relates to the use of OpenCL not GL.
Microsoft and Apple are both adept at making release issues widespread from time to time. Today I read that some corporate self hosted email systems from MS have what is being referred to as the Y2K22 bug. Basically due the date storage field number format chosen ages ago being unable to store the numbers generated by the routine when the year rolled over to 2022. (Not enough bits available to represent the number ) or something like that)
The importance of OpenCL, in recognizable and significant performance terms, seems to be greatest when outputting a large batch of files with significant edits. Or maybe copying some edits across a large batch of files.
In other situations the benefits may be less visibly evident or observable on an image-by-image basis. Indeed there may be none - it depends on what one mostly does with one's editing.
The time to open question may or may not be influence by OpenCL. Much depends on how you use your system.
For example I tend to leave C1 open let the system hibernate. So my C1 open time depends entirely on my system startup from Hibernate time. For reasons I have never really investigated this seemed to jump from almiost instant when new to about 20 or 30 seconds after a Windows/Supplier update a few months ago. It's probably really some other factor and there is a lot of setting up and checking going in the background. But my C1 sessions in use when I was last active will be ready by the time I have signed on via the login to Windows.
It would be interesting to create a C1 startup process flow chart. There seem to be a number of possibilities for flow variations from system to system.
0 -
BeO,
I did mean OpenCL but as it is I do not think it has had that much to do with the slow loading times, I have now disabled window updates on my GPU so at least I have control over that, I didn't use the app mentioned in the article before but changed the computer configuration settings.
It is interesting what you say about hibernate, it is something i have not used for a while as it caused some problems for me but maybe i will give it a go.
0 -
I am using C1 on a Windows Pro 10 machine with 16GB RAM and a 970 PRO SSD. There seems to be something seriously wrong with the hard disk accesses of C1, and it is really becoming unmanageable.
So far, I understood that the catalogue is a database, and a directory appears only if it has previously been imported. However, it looks like C1 does something different, and keeps going to the hard disk.
1) When I am opening C1, it basically blocks completely until the entire folder hierarchy of the library module is displayed. This takes forever. I have an SSD in my computer, but some of the directories link to the archive drive (a physical hard disk), and it often takes 15 - 30 min for C1 to get ready. When I switch off the physical drive it is quicker - but that's defeating the purpose, right? Frankly speaking, I do not understand why any software developer in his right mind would try to crawl through the entire directory tree on opening an application.
2) When loading the hierarchy, it unfolds all folders to the lowest level, and the only way of seeing anything in the directory is to close the directory sub-trees one by one. I am sorry, but again - why would anybody want to unfold a hierarchy to the lowest level? I think the hint is in the work "hierarchy" - you show the top level, and only if anybody asks, you unfold it deeper?!? At least remember what was open and what was closed the last time, and do not force me to close every single branch?!?
Any idea what is going on? I really like C1, but frankly speaking, at the moment it is simply unusable.
0 -
You may all be interested to know that I have raised another support request on this subject but as my original subject request dated 31-10-2021 is still open but not sorted I will not be holding my breath, it is a shame because I have really enjoyed using the program since 2015 till last year......nuff said
0 -
Thanks, Clive. The issue seems to be linked to having old projects on a physical hard disk. To still be able to access them, I set a link to the directory on that disk where the project was before. That works, but if C1 tries to open every folder, it obviously becomes painfully slow. If I switch off the external drive and C1 only has access to the files on SSD the start takes a few minutes, as you describe.
The catalog is consistent. Hardware acceleration has no impact on the file opening behaviour (and why should it), but makes a huge difference in performance - so switching it off is not really an option. Similarly, I would like to be able to search keywords across the pictures, so sessions are not really an option. I could run a catalogue with 200k pictures in Lightroom before without any issues - so I am not really keen on changing my approach to sessions.
To me the Library module seems to be really bad programming. It neither makes sense to access the file system, nor to block C1 until the entire tree is scanned. But this seems to be a known issue.
0 -
Hi Clive,
Thanks for the detailed advice. I think I have a solution which works for me: After "folding in" all folder trees and switching off the "Show pictures in subdirectories", C1 starts at a reasonable speed and also does not unfold all subdirectories anymore.
Yes, "physical disk" was referring to a USB hard drive with rotating disks and heads moving around (a Seagate Barracuda 8TB 7200 drive, to be precise). I am considering migrating to a Samsung 870 QVO which should speed up access.
I am using symbolic links. Having all the pictures on one drive is not so practical, the largest single-sided M.2 SSD fitting my laptop still seems to be 2TB.
Thanks again for your help!
Best
Tom
0 -
Hi, i've upgraded from CO20 to CO23 and got an issue similar to the described in this thread. In CO20, the time since launching the software to when it is fully functional, was 3-5secs, now that i've upgraded it takes more than 30secs. I've tried everything i could think off (to the point of reinstalling windows), but always the same, 30secs or more to load (since the UI is showed to the moment i'm able to pick a picture and start editing), in the meanwhile i can see the folders hierarchy being build, but can do nothing.
I've opened a ticket today and have a response within 30minutes, first they suggested all the things that i previously readed in this topic, with no succes, now i'm waiting for a new response.
One thing they told me was: Every Capture One version does check folder hierarchy at every launch, so it is likely not the case.
Looking through the logs (ImgCore log) 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)
i've started a new thread in the co23 subforum: https://support.captureone.com/hc/en-us/community/posts/7708223524637--Very-slow-start-up-time
0
Post is closed for comments.
Comments
37 comments