Skip to main content

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

C1P crashes

Comments

16 comments

  • SFA

    No it's not normal.

    You have LR imported catalogues and freshly created.

    Do you experience lock ups on both types?

    To eliminate the possibility that some aspect of using a network volume is a possible cause have you tried using the catalogue and any referenced image files when they are installed on in internal drive?

    I think you should start there.

    The "Hard Lockup" is very likely to be annoying but without identifying the cause of the problem amongst the many variables possible in your set up it's difficult to assess the cause.

     

    FWIW I sometime work fully from a NAS drive and there are times when the NAS seems to be extremely slow to respond  - it might be in some sort of self backup or "eco" mode, not sure - and that CAN produce the "no response" message and apparently frozen system. If such a state continues long enough things can fail. I should point out that I use Windows not Mac.

    However it is typically a rare occurrence ( although if I have a lot of applications running and am pushing the memory it seems to be more prevalent).

     

    Grant

     

    0
  • Eric Valk

    For a large number of images (>10,000), Capture One can take a long time (hours even) to import. This has been improving release over release.

    How many images are you importing?

    During a very long import process (V10 and V11, C1 is my main tool and I am no longer importing from other applications), I have seen C1 show the beachball during the import process.

    I have observed two outcomes from C1 being non responsive (if the user doesn't become impatient and kill the process)

    1. It recovers on its own (typical)

    2. The memory allocated to C1 frows and grows and grows. If it gets to be about 4 times the size of the physical RAM, then if the user doesn't kill C1, the whole system locks up and the only possible exit is to power cycle the Mac. (I haven't seen this for quite some time). What I used to do is keep an eye on the memeory allocated to C1. For my system with 16GB of RAM, if the RAM allocated to C1 reached 30GB I'd start to worry. (once the allocated RAM exceeds the physical RAM, it means the OS is swapping RAM to disk. Not a great scenario, but not fatal) Once it got near 45GB, I'd kill C1, because I knew that if it went much above 50GB, OSX itself would become unrepsonsive.

    Once I've killed C1 while a catatog is open (for any reason) then I will always delete the catalog and either restore from backup or cretate a new one. Haven't had to do that in V12 or V13.

    I observed that a corrupted C1 catalog could slow future operations, particularly including the next import. Even if it passes the integrity checker.

    0
  • Lost Carrier

    Thanks for your replys.

    Libraries are a couple of 100 pictures - nothing I'd expect RAM to exceed. Also it locked-up all over sudden - not getting slower and slower (while allocating) memory.

    Yes, this happened for Catalogs on local disc as well as in network. Storage is abolutely fine - never had an issue with Lightroom.

    Actually I'm myself a bit puzzled even where to look next... is there any log file I could look up?

    0
  • SFA

    Yes there are log files. Several.

    As a Windows user I can never remember where they are on Macs.

    Someone will be along to advise no doubt or you could try searching the Community resources.

    Your sudden lock up might suggest a data problem of some sort - perhaps the process discovering an unsupported file type or some other sort of challenge.

    Are your imports taking in new files for the camera or are you converting from Lightroom?

    0
  • Lost Carrier

    Lock-ups happened with both.

    Unsupported files ... yes thought this as well at first. Bit it happened also during re-creation of previews (not importing). And also while regular work on some already imported image (while cropping).

    0
  • Lost Carrier

    Update: Lock-ups just happend while doing nothing (...in C1P / was browsing this forum / C1P open in the background).

    ...also I meanwhile installed it on a different machine (MacMini 2019 / also 16GB RAM).

    0
  • Eric Valk

    Very Strange. I've never had a C1 lockup where Force Quitting Capture One didn't work (assuming I could get to the Force-Quit menu).  And C1 lockups (for me) are very rare.

    Mind you, I'm fairly Unix literate, and if Force Quitting some application didn't work my next steps would be open Terminal, find the Process ID from ps -Ac | grep "Capture One"  and then execute a sudo kill -9 on that pid. That will kill it.

    I can recall two issues mentioned in the forums that might be related to this 1) NAS storage  2) HW acceleration

    I would have a go at not using the NAS and disbaling HW acceleration to se if these affect the lockup behaviour.

    0
  • Lost Carrier

    Yes... Unix know-how shoud actually be less of an issue than C1P know-how.... ;-)

    Wanted to go for "kill -9" as well, but couldn't find any process left after "Force Quit". Must be somewhere hidden - sometimes even the C1P window was still visible, but no process left %-?.

    No NAS would not really be an option for me, but I just disabled HW acceleration - thanks for that hint! Let's see if this helps...

    0
  • Paul Steunebrink

    Your iMac has most probably a retina display. To accommodate for the high resolution of that display, you need to set the preview cache to a higher than the default value, typically 3840 or even 5120 for the 27" retina. You find this setting in Preferences > Image tab.

    Note that you have to regenerate the previews after changing this setting. You can do that from the Image menu. Select the images first.

    This can improve the stability of your setup.

    0
  • Eric Valk

    FWIW for my late 2015 27" iMac with 5K retina display, I am using a preview size of 2048 for both CO12 and CO20.

    I did some measuring by reading the cursor position and that seemed appropriate for the typical size of the image in the viewer.

    0
  • Lost Carrier

    Ok... thanks for your hints!

    So I disabled HW acceleration but still had crashes. IIRC I had to disable HW acceleration in Lightroom as well and after all I don't feel any performance drain (shitty Intel Graphics, I guess), so I'll leave it off for now...

    I switched previews to 5120 (to be save - it's a 4K display), but still had occasional crashes (OK, I thinks it's in-deed a bit better now).

    Meanwhile I'm pretty sure this is because of the network, since...

    a) after some crash Timemachine complained about an inconsistent backup (must have been running in parallel?)

    b) I opened some other app reading quite a bit from that network share -> BAM! ...C1P crashed!

    c) I noticed that after C1P crashes, that network share is not accessible anymore (only "umount -f" helps to enable remounting / C1P still dead)

    Hmm... any suggestions what to try next? ...is this a bug in C1P? I mean I have several other apps (Lightroom, Final Cut, ...) heavily accessing that network share - none of those had such issues up to now...

    0
  • Eric Valk

    In Capture One versions 12 and earlier, I recall quite a number of users having problems with network shares.

    My impression is that it improves release over release.

    I would not put the catalog bundle (contains the database) on a network share. Haven't tried with my referenced images.

    One thing I have done is put a Gigabit switch between the router and my NAS so that traffic between the two does not have to go through the router. Switching occurrs at layer 2 (MAC address based),and is faster than routing, which is done at layer 3 (IP address based)

    0
  • Lost Carrier

    Yep, catalog is local and network setup sounds also similar (Switched, Gigabit) and after all I get pretty decent transfer rates (about 110-120 MB/s for larger files).

    I would understand if C1P blocks for some time if network does not respond, but crashing that heavy!?!?

    0
  • Eric Valk

    I agree. Not good performance.

    0
  • Paul Steunebrink

    @ericnepean

    I did some measuring by reading the cursor position and that seemed appropriate for the typical size of the image in the viewer.

    Note that on a Retina display the real amount of pixels is double the reading of the cursor position, for example when you use Sh+Cmd+4 to make a screen capture.

    @Lost Carrier

    Capture One is sensitive to network latency and make it crash. That is the reason that accessing a session or catalog over the network is not recommended. This should not be confused with a local catalog and referenced images on the network as you have. However, latency can still kill the process.

    Latency is different from the fast or slow network. Latency is the time to respond to a request (in milliseconds). Another network load like a time machine backup or file transfer may increase latency.

    It can be the switch, or the cabling (I assume we are talking all wired connections as wireless has too much latency anyway) that induce more than average latency. For a gigabit network, you need at least CAT5E or better CAT6 cabling to limit latency.

    0
  • Eric Valk

    @Paul_Steunebrink   Can you comment:

    The image dimension (in real pixels) is rarely exactly equal to one of the preview size settings available in C1.

    Is it better to have a preview size setting slightly larger than the typical image size in your workspace, or slightly smaller? For this purpose should one consider the horizontal dimension or the vertical dimension or the larger of the two?

     

    0

Post is closed for comments.