C1 does not quit
Hi,
every now and then C1 (13.1.2.37) does not quit when you invoke File > Quit. It happens sporadic and I do not see any pattern to that.
This is very annoying because the only solution is to force quit the application which risks damaging the catalog.
Is anyone else seeing this?
-
C1 can still be undertaking some background tidy-up tasks when it disappears from the screen. In my experience that usually inly takes a few seconds but sometimes I have seen about a minute. (Using sessions) .
If you are using a Catalog do you have a catalog backup schedule set in the Preferences file?
Or any other backup application that might be preventing C1 from closing out the application?
Beyond that I very rarely see system type glitches, usually when running a lot of applications and being low on system memory and/or disk space which can cause some slow activities. But that's rare and I use Windows so likely there are differences.
0 -
No, I do not have catalog backups turned on and the external SSD with all C1 files is not being backup up.
I noticed that it takes a couple seconds to close large catalogs. But this is not a matter of not waiting long enough. It does not quit within at least 30 minutes.
0 -
Same problem here.
I opened a ticket on 17 July and support is trying to solve the issue but, so far, they are keeping asking logs and beside few total reinstall (that did not solved the issue) no clues at all.
macOS 10.14.6, CO 20 (13.1.2.37)
I only use sessions and actually it is not possible to quit the app if I work for few hours – the only way to quit is to force quit. hopefully this does not mean I risk to loose edits I made to the last few images...
In the last answer support told me it might be my system and not a bug, but now that I see I'm not alone I'm wondering how many other customers are facing the same issue...
0 -
Thanks for the update. I have been asked to reinstall as well. My log files didn't show anything suspicious to me. As I continue working with C1 it does not appear to be system related to me. I don't see any activity from they about this issue other than waiting that it magically solves itself. I guess the only way to get more insight would be a debug build that writes more log files that will show them at which point the application fails to quit.
Tip: you can create a catalog (and probably session backup) from the file menu before force killing the application. That way you have a safety net in case force quitting corrupts the catalog/session.
If anybody else is seeing this behaviour, it would be nice to contact support so that they know that there are more affected users.
0 -
"I don't see any activity from they about this issue other than waiting that it magically solves itself."
unfortunately I have the same feeling...
"a debug build"
this is what a serious company taking care of their customers do.
"If anybody else is seeing this behaviour"
I'm not sure bout how many people are on this forum, probably is time to spread this issue in different ways, thinking about socials, facebook groups, etc. and see what happens.
0 -
I have updates about this problem! It appears to me that this definitely is a bug in Capture One. The application seems to loose track of which operations are still pending and which have already been completed before being able to safely shut down. It shows on my system in the log files as follows:
2020-10-04 09:18:26.956 (Thread 0x105553126461952 UI) *** Initiating Capture One Termination Procedure ***2020-10-04 09:18:27.009 (Thread 0x105553126461952 UI) Activity threads finished shutdown2020-10-04 09:18:27.011 (Thread 0x105553126461952 UI) Shutdown BatchQueue started2020-10-04 09:18:27.024 (Thread 0x105553126461952 UI) Shutdown BatchQueue finished2020-10-04 09:18:27.028 (Thread 0x105553126461952 UI) Layer "Berge Hintergrund betonen" of image "DDT_6536" (128) has pending changes. Cancelling document close.2020-10-04 09:18:27.029 (Thread 0x105553126461952 UI) Shutdown interrupted: Document file:///Volumes/Capture%20One/Capture%20One/2019.cocatalog/2019.cocatalogdb2020-10-04 09:21:27.525 (Thread 0x105553126461952 UI) -[CatalogDocument _coalescedAutosaveForce:] (object: 0x7ffc5c61ec90) Autosaving /Volumes/Capture One/Capture One/2019.cocatalog/2019.cocatalogdbHowever, these pending changes never seem to be saved (or reverted) and as a consequence you are unable to quit Capture One. There seems to be no feedback about this in the user interface. If you're affected by that problem, you can check the log file com.captureone.captureone13.log to see whether it has the same error messages. Please note that this log file was renamed and the instructions on how to submit log files have not been updated and therefore are inaccurate.I have to say that interacting with the Capture One support has been the most abysmal support experience that I have ever had. They simply are not reading your messages, do not check any of the log files you submit, reply only with pre-made text blocks that point to outdated support pages which only seem loosely connected to your problem. Most of all, that process seems to be designed to keep you busy and stop trying to get your problem resolved. That process shows an utter lack of empathy and respect towards their customer base. As a paying customer, that does not feel good at all...0
Post is closed for comments.
Comments
6 comments