Browser skips the next image after deleting an image
I am using C1 version 16.3.8. I have noticed an odd behavior in one catalog when deleting an image thumbnail in the browser. The problem does not occur in my other catalogs.
If I delete an image, the display focus skips not to the next image, as would be expected, but to the one after that. If I delete 2 images, the focus skips not to the next image, but to the one that is two images after the deleted image. In short after deleting an images/thumbnail, focus location skips to the next image + the number of images deleted. This can be quite confusing when expecting the next image to be displayed in the viewer. The problem does not occur in my other catalogs.
I am not sure if this behavior started with the update to version 16.3.8 or after I was using that version. I did a verify and repair on the catalog even though it appeared to be working (catalogs often show verification errors that can be repaired that do not otherwise affect the function of the catalog). Could a corrupted core settings file be the cause and if so, what file needs to be replaced and how would be the best way to do this? Since the problem is only in one catalog, what could cause this problem inn just that catalog?
-
Addendum: This problem (skipping image focus) actually does occur in all catalogs when viewing a newly imported image. If the imported images are moved out of the catalog and become referenced files, the next image becomes the focus after the deletion(s). The problem also does not occur after the catalog is closed and reopened after importing new images.
Therefore, the problem is most likely not in a catalog, itself, but is related to something that is fixed by making managed into referenced files, or just by closing and reopening the catalog after an import.
0 -
Follow up after filing a support request:
The problem appeared to be related to a settings file. Support said it could be fixed by executing the command delete com.captureone.captureone16 from terminal. Oddly, nothing happened without first deleting it in Finder. Support staff said the process would remove a plist file, but there is no such file, com.captureone.captureone16.plist, I can find in my user library, just a folder named com.captureone.captureone16 with some microsoft named files. Before testing to see if the problem was fixed I exited Capture One and rebooted the computer and then confirmed that the problem was resolved and that Capture One had been reset. You can tell the app was reset because the various default setting were present.
Unfortunately, after the computer slept overnight, when I reopened Capture One, the problem had returned. The only thing I had done was to manually restore the settings that had changed. The problem again goes away if the image files are moved to a referenced file location, or if Capture One is closed and the catalog reopened after importing files. It also does not occur while images files are deleted in the recent imports folder.
Very strange, but fairly easy to get around.
0 -
there is no such file, com.captureone.captureone16.plist, I can find in my user library, just a folder named com.captureone.captureone16 with some microsoft named files
Perhaps that along explains the issue?
Did you mean "defaults delete com.captureone.captureone16" ?
That will delete the cached property list and should also delete the property list (.plist) file.
This file would be in Library/Preferences under your home folder.
0 -
I did enter defaults and delete com.captureone.captureone16,but on separate lines. This is how the staff said to do it. It does not recognize the command sequence when typed together on the same line.
Where exactly are these property list files you refer to? The only way to see if the change is persistent is to check the files' modification dates. If the plist file is not on my system, this might cause some odd behavior. The only appearance of a com.captureone.captureone16 plist file is a file named Error - com.captureone.captureone16.plist. This file is located in Application Support/Capture One and is a rather old old file not deleted. This implies there was such a plist file at one time.
Of course it is possible that the files were removed, but are not causing the problem.
0 -
Preference (property list) files are in Library > Preferences under your login's home folder.
0 -
I copied your command "defaults delete com.captureone.captureone16" and it worked, today without giving me an error message, so I will see if it corrects the problem. I still would like to know where that plist file is located so I can check to see if it is updated.
0 -
Walter,
Thanks for the guidance, especially finding the preference file.
I think support though that anything with defaults delete com.captureone.captureone16 would include defaults delete com.captureone.captureone16.plist. It dose not. You have to be specific, apparently.
I watched as defaults delete com.captureone.captureone16 was executing and it only changed the time signature until I changed it to defaults delete com.captureone.captureone16.plist. This does not actually delete the file but it empties it except for a short header. Capture One restored it when it reopens.
I also suspect this is not the whole story of how to fix the problem. It remains unchanged. I bet when I thought it was working, I was testing it in the new imports folder and not the actual album into which I thought I was importing it.
I have updated my support request.
0 -
Walter, I wonder if leaving old installations and not uninstalling them when installing new versions causes problems. Capture One does not address a need for uninstalling old versions and their associated files and the uninstall process is a bit of a challenge. Are there any known problems with this?
Some will wonder why I keep old versions. I keep the old versions of my catalog and their corresponding old Capture One versions just for redundancies sake. The process of completely removing a version is tedious and if I want to have access to the unconverted catalogs, I need the old versions to open them. This is admittedly overly OC.
0 -
Speaking strictly from personal experience on macOS I had an issue with a recent update. Each time Capture One started it wanted to rebuild the acceleration kernel. While I did not have prior versions of the app installed, the acceleration kernels from prior versions were present. Removing all image kernels including prior and present versions, and letting it rebuild from scratch, was the resolution to my issue.
It is conceivable that older preferences files also can cause issues. I also have seen corrupt preference files cause issues. They are very sporadic and could be due to macOS bugs vs Capture One.
0 -
What are the acceleration kernels named and where are they located? Did you remove them with Terminal or with Finder?
0 -
I have attempted to isolate factors related to eliminating the odd behavior of thumbnails being skipped beyond the next thumbnail when a thumbnail is deleted. Turning off acceleration or removing config pref files or reinstalling Capture One did not fix the problem. I found the following relating to thumbnail* skipping:
1. Import into Recent Imports and delete thumbnails from there - no skips while in Recent Imports
2. Move new thumbnails from recent imports to another album and delete new thumbnails - skips still occur
3. Move new thumbnails from Recent Imports or from any album the new images were imported to and then move to any other album and delete new thumbnails - no skips
4. Import new thumbnails into any album, delete all of the new thumbnails, the restore the new thumbnails with cmd + Z and delete new thumbnails - no skips. This seems to be the easiest workaround, odd as it is.
5. Import new new thumbnails, close Capture One and reopen it and delete new thumbnails - no skips
I bet this is an unusual problem and not likely to be seen by others or on my other computer. I am traveling and will need to check the other computer when can. Meanwhile, there are several workarounds.
Somewhere in all of this is a clue to the cause of the problem.
________________________________________________
* I am referring to the thumbnails as I would images.
0 -
You cannot "delete" images from Recent Imports. That DELETES them from the catalog. You also cannot "move" them out of Recent Imports. The Recent Imports dated albums are entirely managed by the app.
0 -
Of course. You do have to be careful about deleting from Recent Imports because of what you point out. This is not something I would normally do unless I really wanted to directly delete the image from the catalog, which is a problem prone strategy. I did it using my test catalog to help me find how this bug was behaving.
I should have better described what I meant by “moving” images from Recent Imports. You cannot move an image out of any album or Recent Import, but you can drag their thumbnails (move by copying) to another album. That is what I meant. Deleting the dragged/moved images from the original location requires explicit deletion from that location. I used to think this was a pain, but it is actually a good feature.
This still leave the question about what s bugging my installation of version 16.3.8.
0 -
It might be worth perusing the 16.4.x release notes to see what issues were resolved. I don't recall anything specific to this but I don't memorize them.
0 -
Don’t recall seeing this bug mentioned and I suspect it is unique to my installation or more folks would have reported it. This is the only bug I have found in 16.3.8 and I otherwise find it quite stable. What causes and corrects the problem is not going to be easy to figure out.
0 -
Try this .. create a new empty catalog, then import the existing catalog into it. This won't affect the existing catalog. Then test the new catalog and see if it exhibits the same issue. If it doesn't then use the new catalog and delete the old one. If the new catalog exhibits the same issue, the delete it and go back to the existing one.
0 -
I tried importing the catalog into a new catalog, but it did not fix the problem. I also did a full verify and repair. The verify often fails at this point in both of my catalogs, not only with this version, but is always fixed by running Repair:
Checking for catalog folder collections without a project
FAILED!
Checking for catalog folder collections without a project done
Database content error
The database failed verification.
I do not have any folder collections (the meaning of which is unclear to me) without a project that I can find or that have been repaired. Also, the Repair works, but sometime later when I run a Verify and Repair it happens again, in any catalog. The error does not seem to have any effect and is never reported when doing the more abbreviated verify when backing up the catalog.
0 -
I recommend opening a support case and providing a link to this thread so they can read it for details. I also would provide a copy of the catalog of you can so they can analyze it..
0 -
I did open and update a support case and detailed the steps I have taken to explore the cause of the problem. Support seems to be in the mulling over stage after recommending replacing the plist. It could be the catalog is at least part of the problem, although it happens reproducibly in several unrelated catalogs as well as newly created ones. The things that stop it make it seem more of a conflict in between Capture One and other concurrent processes. It did not happen before the last update to 16.3.
I think this, like so many odd ball bugs that people discuss on the forum that are not seen by others are due to the interaction of Capture One with other process, although how this would explain what I am seeing is way beyond my expertise.
0 -
The support team responded today with the following (italics):
Thanks for sharing the video and sample files we can use for testing.
I've checked this behavior in version 16.3.8, and I could perfectly reproduce it, albeit in an Album inside a Project. However, moving on to version 16.4.4, this wasn't a case any more – it could've been fixed in an update.
Thus, I suggest that you check if the issue occurs in the new release.So, this is not the result of something unique to my system. It is now a known annoying reproducible bug in an otherwise adequate version that is not going to be fixed under the new update/upgrade plan. Fortunately, it is a small annoyance, but it would be better when a bug can be confirmed in the same major version, that it could be fixed in a routine update rather than an upgrade to a new version.
0
Post is closed for comments.
Comments
20 comments