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. ⚠️

Inordinately Long Start Up Time.

Kommentare

4 Kommentare

  • SFA
    David,

    Sometimes my C1 is a little slower than others when starting up - seems to be a Windows thing mainly as the same can be said or other applications. However never anywhere near as long as 5 mins. 20 to 30 seconds maybe. SSD but no internal second data drive.

    On the other hand I don't use a catalogue, I do have large sessions but not as large as your catalogue and I'm using Windows 7 Pro. This machine is a notebook rather than a desktop.

    When you say star tup - from first click to a usable editor or form first click to any sort of screen response?

    I have, recently. noticed periods when the entire machine seems to freeze - all applications - for a minute or two. Not sure why. I'm slightly suspicious that the disk light is on constantly at those times. I wonder if it is some sort of internal housekeeping on the SSD since I seem more than capable of filling it very quickly both with images and with some non-photo software I am testing which can tend to create some extremely large sqlserver database work files.

    It may be worth running the Windows activity monitor screen to get an idea of what is and is not active during the delay but my guess would be that at first machine start a temp workfile database is generated for the default/last active view - in your case the large catalogue. Once created it should be quite fast to work with and the database server will most likely keep in "in memory" in the Temp folder. It is lost when the the machine is shut down (not unreasonable) and a version of the DB will be created at next C1 start.

    You could try proving that theory by creating a very small Catalogue and closing C1. Then re-boot, restart C1, see if the 'recent' Catalogue is selected and observe how fast the start up is.

    HTH.


    Grant Perkins
    0
  • Dave R
    The time is from the small Capture One logo panel appearing till the full editing screen appears. I had the activity monitor running during the 5 minutes and it showed Capture One as not responding but using a few percent of processor time, quite a bit of disk access time and as much as about about 30% of my RAM (which as I have 32gig is about 10gig).
    The problem is that the problem is so inconsistent. I just restarted the PC after it had been completely shut down for 6 hours and Capture One only took 10 seconds to start up and open at the image I had been editing when it was last shutdown - a perfectly acceptable performance.
    0
  • SFA
    [quote="David532" wrote:
    The time is from the small Capture One logo panel appearing till the full editing screen appears. I had the activity monitor running during the 5 minutes and it showed Capture One as not responding but using a few percent of processor time, quite a bit of disk access time and as much as about about 30% of my RAM (which as I have 32gig is about 10gig).
    The problem is that the problem is so inconsistent. I just restarted the PC after it had been completely shut down for 6 hours and Capture One only took 10 seconds to start up and open at the image I had been editing when it was last shutdown - a perfectly acceptable performance.


    Hi David,

    Tricky to analyse through a forum dialogue.

    I don't think the RAM matters much in this situation. I have 24Gb but I rarely see the system, no matter what is running or how many instances of C1 session I have running, getting much about 60% of that. If I really push a couple of browsers with each having plenty of tabs open I can get to about 20Gb used. Maybe C1 would demand more memory of I was working with huge files - Phase back generated for example.

    I would guess that what you are seeing with the short startup time is a situation where the last edit is being invoked by default and all the working files are to be found just where they were - basically a restart from something like a hibernated state rather than a full shot down (I use that as a an illustrative description rather than a statement of the process you make have been through).

    Your longer example might be the equivalent of a total close where, as the default last used files are re-opened, the workfiles for them, typically the display renditions for previews, may no longer exist in the temp work area and so are being re-generated. That might take a while. Another possibility that has come up in discussion before is that the default preview size in your preferences my not be optimal for your screen resolution. If the default is larger than your screen native size the stored pre-views would need to be re-sized before display. In overall perceived performance terms there will always be a trade-off between doing this as a one-off exercise for the whole set at start up or doing it on the fly as a file is accessed or some sort of hybrid where on-access demand is satisfied while background processing deals with the whole batch. The same issues exist in any data processing environment and there is no single answer that is right for all situations that everyone will be able to agree about. You may know this already of course.

    However that is speculation. Until you can pin down what is going on in the slow start situations it's difficult to know what to suggest next.

    HTH.


    Grant Perkins
    0
  • Dave R
    I solved the problem by deleting the cataloguue completely and reverting to working in session mode only. Everything is now very slick. 😎
    0

Post ist für Kommentare geschlossen.