NNN636499562226890496 wrote:Bobtographer wrote:what happens when you set the refresh to 60?
When I change my refresh rate to 60, the problem still persists.
SFA wrote:Purely as an experiment try turning OFF (Setting - "None") Hardware Acceleration in the C1 preferences.
When you mentioned C1, I thought you were talking about CPU power saving management (C1, C3, C6, etc) config available in motherboard BIOS. (Without knowing that C1 stands for Capture One...lol)
Anyhow, that actually reminded me that I recently re-enabled C3/C6 states for CPU in BIOS, right around at the same time when Capture One stopped working. It was previously disabled due to an annoying buzzing noise issue. I just could not correlate Capture One and CPU power saving management feature on top of my head.
Since I did not want to disable C3/C6 states in BIOS, I proceeded to download the latest BIOS firmware for my motherboard from the manufacturer's website. After updating from motherboard BIOS version from 1.3 to 4.1 (latest), the freeze issue that I have been encountering with Capture one is gone! I can zoom-in and zoom-out on my images all day 24/7.
I am happy that you helped me resolve this issue, and also happy that the root cause of the issue is not Capture One, but my hardware component. I was able to work on hundreds of images last night.
Who knows why Capture One was the only process that was causing my system to freeze, but I am relieved my computer is stronger(?) after updating BIOS and can withstand Capture One.
Thank you so much for your help. I really appreciate it.
Great news!
Not what I would have known to suggest but so many of these things are interrelated. I could imagine something to do with the GPU/driver being an issue after windows updates and given the point at which the failure seemed to occur. However even fixing that via a driver update might have been, in effect, a patch by the driver developer to get around an incompatible BIOS problem.
However if the issue just related to power settings it certainly seems weird but goes to show how the inner complexity of running computers is hidden from the user!
I suspect that the reasons other application where not affected is that either they do not use the particular modules that did not match the BIOS or they use their own controlled releases of certain routines rather than the latest and greatest Windows offerings in order to avoid potential stability issues at the possible cost of taking advantage of new functionality, speed enhancements, etc. Another option would be to ensure random variables - like power settings perhaps - are turned off by the application when it is active overriding system settings in some way.
That sort of strategy was very common with certain widely used components like Java, for example, a few years back.
If a developer was not entirely confident that they could rely on continuity as some important third party software component was developed they would freeze things for their application at a known and acceptable point by installing an earlier version and ignoring whatever the current version might have been updated to on the machine on which the application had been installed.
Eventually, of course, support for the older version would stop and the writers of other parts of their software tool kits would move on to the new version only thus forcing things to change - often with a lot of effort required for no evident functional benefit.
None of that helps when something surprising happens without an hint of a possible connection to a root cause - as in your case.
One of the reasons I have stuck with Win 7 is simply because with so few changes being applied I felt it was likely that its maturity and stability would be an advantage compared to Win 10.
These days Win 10 seems to have some degree of maturity but the way the updates are handled leaves me some cause for concern, though less concern, perhaps, than in the first 2 years or so of its existence.
Anyway, you have your system back and working as needed so all is well.
Grant