Zum Hauptinhalt gehen

Problems upgrading catalog from 15.x to 16.3

Kommentare

57 Kommentare

  • John Friend
    Top Commenter

    BeO

    I don't think I quite follow what you're saying here. 

    I have my Capture One configured with browser, viewer, toolbar and tools all visible.  I don't change that on my 30" monitor.  So, all my reports are from that configuration.

    When you say "concerned image" are you saying that you think you have a particular troublesome image that can cause this?  Also, are you using legacy previews or new previews?

    0
  • BeO
    Top Commenter

    I have left the default preference settings regarding previews.

    I have edited a few images which means preview is being rebuilt. If I show the toolbar and the browser the CPU is behaving normally. If I hide the browser (key G) and show the viewer instead, the CPU goes up and keeps doing something, though I only look at the image.

    Yes, some images are concerned, others are not. The edited ones seem to belong to the concerned images but others seem to be concerned too.

    0
  • Jerry C

    Does the CPU activity increase when viewing just the viewer new with version 16.3? 

    Does the CPU usage go up if you view both the browser and viewer on separate displays?

    0
  • BeO
    Top Commenter

    Hi Jerry, 

    In my case, yes, with 16.3.1 the CPU is going from <1% (browser) to approx. 40% (viewer), then eventually settles at 32% or 22% after a minute or two. Zoom to fit or zoom to 100% doesn't make a difference. In my test I always had the toolbar visible as well.

    Hardware is Dell XPS 13 with integrated gfx card (I don't test v16 on my desktop machine), screen resolution 1920x, preview size setting is 2560 but could have been smaller in the past.

    I don't use a 2nd monitor.

    0
  • Jerry C

    Walter,

    Thanks for reminding me about the Cache and separate Preview files. Interrupting regeneration of one preview one does not risk affecting anything but that preview, unlike apps where everything is in a monolithic database.  Good to know you have actually tested this with a force quit. It does make me wonder why Capture One does not allow one to quit regenerating previews, which would be handy if needed while regenerating a large catalog's previews.

    A question remains. If regenerating previews with the entire 65k image catalog is interrupted, when restarting regenerating the previews, does Capture One go back to the beginning, skip regenerating previews of the size specified in the settings and take up where it left off, or something else?

     

    0
  • BeO
    Top Commenter

    Hi Jerry, I think you can create a small catalog by exporting a collection as a catalog. Look at the .cop files modified date, start regenerating previews, interrupt, look at the .cop files modified date and start again, and finally look at the .cop files modified date when finished. This file modified date should tell for whatever scenario you would be testing.

    0
  • Jerry C

    I installed 16.3.1 and regenerated all of my previews. Many previews had previously been smaller, so the size of the preview cache (which accounts for most of the bulk of the catalog) increased  the catalog size from 121GB to 170GB in regenerating them to the 5k recommended size for my 5k monitor.

    Browsing from image to image in the browser is faster after regenerating the previews, taking a small fraction of a second to view full resolution. I am still not convinced that there is a substantial, benefit to following the recommended image size ether for appearance or efficiency on a fast computer, but as media for storage gets less and less expensive, it is not a big issue.

    Editing an image while regenerating the previews showed no discernible loss of smoothness. CPU activity was distributed evenly among all cores. CPU load was not quite 27%, almost all due to Capture One. It took around 6 hrs to upgrade the 65k previews.

    A few odd things:

    After configuring the setting to upgrade previews, clicking on a project immediately triggered a regeneration of the previews for that project. When selecting All Images, the same thing happened, but only for a few thousand images. Until these previews were regenerated, I could not move to another project or folder, although I could edit an image and its metadata as usual. This might have been the source of the apparent lockup others have experienced in upgrading previews. Fortunately, it never happened again after this.

    The progress window says all processes will continue in the background allowing you to go on with your work. You can edit a variant or metadata, but if you navigate from All Images or a project to another location regeneration quits. Capture One does not continue from where it left off, either. There is no way to know where the regeneration process left off, so you have to repeat the whole regeneration process from the start. So, if you want to set your catalog to regenerate all previews, your ability to work in the background is quite restricted and ought to be done in manageable batches or when you are sure you do not need to make use of the catalog. I saw this sort of things in previous versions of Capture One, so I do not think it is new to version 16.3.1. The preview regeneration process needs to actually work in the background or be able to restart from where it left off.

    If you purchase Capture One as a new user, not only do you get the 50% discount, and you do not have to change the activation code for version 16.2. In essence, you have 2 licenses.

    0
  • BeO
    Top Commenter

    Win10, C1 16.3.1, session.

    After a lot of testing trying to find the root cause I did not succeed. I even moved all images from that folder to a new one so that old cache files eventually gathering in the Proxies folder (e.g. from accidentially deleted images with Explorer) would be left behind, and then regenerated all previews again.

    I still have the issue that for some images when loaded in viewer the CPU is doing something forever:

    and as soon as I show the browser in addition to the viewer, or switch to the browser by hiding the viewer, or switch to the previous image the CPU stops doing what its doing

    My hypothesis was that the close proximity to some DNG panorama images (roughly 15 image ahead) causes C1 to preload the proxy (which is not a jpg I think) and recalculate the preview based on the proxy + tool settings. Because approaching an image in the viewer not too far away from these DNGs via the next button is the best way to reproduce the issue. So I moved the dng files out to a different folder. But it did not solve the issue.

    Oddly I discovered that moving DNG files from the browser to a folder in the library tool seems to have a bug, i.e. the .cof files (which are next to the .cop files in the Proxies folder) are not reliably moved, that is not always all of them. Then I moved them using the Explorer so that they do not impact my test.

    So, CPU-busy issue remains and a new bug discovered (though I don't know if it is a new bug or an old one because the additional left over .cof files in the Proxies folder nor the missing .cof files in the target Proxies folder of the image move operation, did no apparent harm. Maybe I also need to re.check 15.2 if the CPU-busy issue exists there too.

    EDIT: The bug that .COF files are not moved not only conerns the .COF files of DNGs, if I move NEF images only it occured now too.

    0
  • Walter Rowe
    Moderator
    Top Commenter

    BeO .. my experience is that Capture One is not as tidy as we want it to be. I've reported this in the past (long ago). It clearly has not been addressed.

    0
  • BeO
    Top Commenter

    Hi Walter Rowe,

    I double checked this folder with its images again with v15.2 and whatever I do I cannot provoke the cpu-busy issue.
    (15.2 is quite good. in later builds they introduced regression defects and oddities, e.g. cos files being updated when showing the thumbnail in the browser (a nightmare for incremental backups), or when switching beween existing layers, and others.)

    Then I went back to 16.3.1 and I can provoke it again, with some images. I tried to isolate the root cause, rebuilt previews, deleted them, deleted thumbnails, reset all images, even deleted cos files, investigated .cos files everything I can think of, except looking into the cosessiondb. I also restarted C1 in between most tests (to remove potential information in the running process) but no success.

    I think a prerequisite is to delete newly created layers. And a hidden thumbnail browser, after having shown the browser. And more than 10 images in a folder (with 44 images in a folder I could reproduce it).

    Unlike with v15.2, the .comask files of images with all layers removed, are not deleted after shutdown of C1, that's a real difference. So I also experimented with manually deleting .comask files so see if it can stop the busy cpu, with and without restarting. 

    (Aside from the cpu busy issue, why the heck are the .comask files not deleted if all layers removed? As long as C1 is running they are needed for the Undo operations, but after shutdown of C1 they should get purged)

    But I cannot nail the root cause. Why does it the cpu get busy with the same images, reliably, but not with others.

    Point is, on my notebook I cannot accept running C1 with busy cpu when it is supposed to do nothing, as it drains my battery, heats my legs and the burned CO2 helps warming the climate; it is the opposite of the idea of Apple silicon chips utilizing efficiency cores when there is not much to do.

    Then, I am a little underwhelmed with the AI masking as such (the UI is good but the result is often only mediocre).

    And even for the Black Friday price, as long as they stick with the current bug fix policy, this 16.3.1 is not a version I have faith in and hence most likely will let it pass. Pity that is.

     

    1
  • Jack W
    Admin

    John Friend BeO Regarding high CPU usage, have you made the tech support team aware? It's the only real way that we can get to the bottom of issues like this. 

    There's a lot of comments and findings on this thread, if anything particular needs addressing then just @ me – I'll be happy to provide my insights where possible. 

    0
  • BeO
    Top Commenter

    Thank you Jack-W,

    No, I did not make them aware. I tried hours to isolate the problem so that it can be reliably reproduced, at least by me, but...

    Though I could reproduce it (but the steps are hard to explain) on some of the images in the viewer for a given folder, it is only in combination of some actions in the thumbnail browser. And when I copy the folder or its images then it might occur for other images. The log files don't give a hint either, at this point in time when it occurs, at least.

    So I am not sure I can make a good bug report, or if it can be reproduced on any other machine.

    But I have reported a different bug yesterday (Blurry image for 1/2 sec. when moving exposure slider, hardware acceleration not working even after kernel rebuild and driver updates, #213125) which was initially brought up by another user, so that can be reproduced, and both of us think that hardware acceleration is not working. Maybe this issue boosts or even creates the issue I tried to describe here (cpu busy though C1 should do nothing).

    0
  • John Friend
    Top Commenter

    Jack-W

    I filed a support request with full log files 5 days ago and have not heard anything from anyone.

    0
  • Jack W
    Admin

    John Friend There are longer wait times in support at the moment. With something like this, I do expect it to take a few days for your logs to be looked at and to match it up with other reports that we have to see if there is a common theme, where we can then look towards a fix if we are able to reproduce what you are experiencing. In any case, we do appreciate you providing the requested information – it will just require a fair amount of digging.

    BeO The latter behavior that you describe seems similar to what some users are experiencing on M2 machines, as outlined in this post here: https://support.captureone.com/hc/en-us/community/posts/11542008161053

    Even though you're on a PC, I'm glad you reported that to us. But as outlined above, support has quite the queue of requests right now, and it might be a few days before they can put the pieces of the puzzle together and provide a response that can be acted upon, or at least shows that we're working on the issue at hand.

    I'm sorry for the wait times you've both experienced, but your requests are in capable hands and I will ensure that the discussion in here is followed as developments happen.

     

    0
  • BeO
    Top Commenter

    Jack-W

    Maybe. But the tech support is justifying the behavior.

    https://support.captureone.com/hc/en-us/community/posts/15058468276381/comments/15094132022813

    I did not grasp when the described (and justified) behavior was implemented, nor do I understand why it needs to behave worse than in 15.2.
    They also did not explain why the "focus mask test" fails in 16.3 (test to verify whether or not hardware acceleration is actually working).

    It is either a wrong analysis of my and Jan's issue - or a bad design decision (because it affects us negatively). Anyways they closed my ticket. Of course I reopened it.

     

    0
  • Jerry C

    Capture One 16.3.1.23 fails the focus mask test on my M2 MacStudio Ultra with 128GB RAM, but is the focus mask test valid for version 16.3? Scrubbing any of the sliders back and forth increases GPU usage from 6% to 42%, whatever that indicates regarding hardware acceleration. 

    The duration of blurriness on my Mac Studio is barely noticeable unless the RAW image is viewed at 100%. The blurriness is not seen with JPGs. There is no difference between setting the hardware acceleration on or off. The blurriness issue was worse with version 16.2 on my iMac Pro even with images zoomed to fit and turning on hardware acceleration had no noticeable effect. 

    So, you can almost eliminate the issue with enough computer power, but why have hardware acceleration if it is not effective. Also, how does Capture One define effective (change in processing speed, slider smoothness, export speed)? To what processes should hardware acceleration apply? 

     

    0
  • BeO
    Top Commenter

    I did not test 16.2.

    Scrubbing the exposure slider back and forth shows cpu (almost 100%) and gpu (approx. 50%) usage, (see the graphs, not the numbers) whatever that means, very similar for both versions 15.2 and 16.3:

    But the blurriness issue only occurs in 16.3 (I did not test 16.2) and is quite annoying. 

    Focus mask test succeeds in 15.2, fails in 16.3.

    I don't see any speed improvement in16.3 elsewhere during editing, so nothing can justify the blurriness annoyance on my computer.

     

    EDIT: The GPU graph is quite idle when I set HW acceleration to Never, so that graph really indicates whether it is used or not.

     

    0
  • John Friend
    Top Commenter

    Do you guys realize that you've really hijacked this thread and are now talking about a completely different CPU/GPU issue than I originally posted about.  I wonder if this could be split out into its own thread by a mod?

    0
  • John Friend
    Top Commenter

    Jack-W

    How long do I wait for a response to my support request?  I'm at 6 days right now (some of which could have been holiday for US based personnel). 

    I ask because my last official support request never received any response, even after I pinged it several times so that's my concern.

    0
  • BeO
    Top Commenter

    Do you guys realize that you've really hijacked this thread

    Sorry John,

    https://support.captureone.com/hc/en-us/community/posts/15058468276381-Preview-becomes-blurry-for-a-moment-when-I-adjust-the-image

     

    0
  • John Friend
    Top Commenter

    I have since discovered that my original problem here apparently has something to do with my user profile stuff (the contents of c:\users\username\AppData\Local\CaptureOne) because when I rename that to CaptureOne.bak, then run 16.3, I can open my catalog successfully without the infinite CPU loop.  So, something in the profile must be related to the problem.

    Also, I finally got a response from support on my bug report about infinite loop CPU when opening my 15.x catalog with 16.3.  They requested that I upload my catalog to the bug report.  I have done that and also uploaded a ZIP file of the profile directory that apparently triggers the problem.

    0
  • Walter Rowe
    Moderator
    Top Commenter

    John Friend – I think that folder also has the hardware acceleration data (it does on macOS). I also wonder if you have any styles in there that have ICC profiles or other nasty things that can foul up Capture One. If you put the old folder back, and just rename the individual folders inside there one at a time perhaps you will narrow it down to which folder is the culprit. Also check the Batch folder. Capture One is notorious for NOT cleaning it out even if you "clear" the batch history.

    0
  • John Friend
    Top Commenter

    Walter Rowe

    I've provided support with the profile directory, the catalog and all the logs per their request.  We'll see what they learn.  The logs probably give them a general idea of what's going on in the infinite CPU loop as it is logging stuff constantly during the infinite CPU loop.

    Yes, I could try to debug their problem, but frankly I'm hoping they can find their own problem and that will lead to a software fix.

    Yeah, I noticed when zipping up the profile directory that it has a ton of junk in it (particularly in the batch directory).  They really don't clean up after themselves do they?  There's also all sorts of stuff in there from earlier versions of Capture One.

    0
  • John Friend
    Top Commenter

    Support has finally responded to my support request and, after asking for some additional information and investigating it a bit on their own, has turned it over to engineering for further investigation.

    0
  • Walter Rowe
    Moderator
    Top Commenter

    That's progress. Good to hear.

    0
  • John Friend
    Top Commenter

    After investigation by engineering, support reported this:

    "It seems like the issue could be resolved by turning off Auto Sync Sidecar XMP in 16.3.x before trying to upgrade the 15.x catalog.

    As soon as you upgrade your catalog, the Auto Sync Sidecar XMP can be turned on again. We are aware of this issue and work on fixing this behavior, but luckily, we have a solution like this."

    That would explain why the issue went away when I nuked my profile directory and started over from scratch because that option is off by default.  I don't think I need that option on any more so I can leave it off.

    2
  • Walter Rowe
    Moderator
    Top Commenter

    This is great news. They know the problem. There is a work around. They are working on a fix. Thanks for sharing that news.

    1

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