⚠️ Please note that this topic or post has been archived. The information contained here may no longer be accurate or up-to-date. ⚠️

"Undo" is messed up again in 7.1.x

Gregg Le Blanc

2013年07月12日 17:33

Hi there,
So my CO7 "history database" (or whatever records my processing steps across sessions) is corrupted again. Yes, I'm still working in sessions, not Catalogs (the behavior is the same - Catalogs didn't make me happy once I couldn't re-point the media I had to move from one location to another and keep my edits).

In 6.x and in the 7.x betas, the only way to fix this was doing a "Complete Uninstall" like this:

(Which isn't quite the same in Windows 8 as Windows 7.)

But when you do this, you lose ALL if you crop settings, workspaces, and output recipes.

Does anyone know how I can export all my CO7 customizations, do this uninstall process, and then get my workspace back? Or just nuke this Undo History that's corrupted for CO7?

Right now, if I accidentally press "CTRL-Z" it may undo a single operation (say, a contrast curve adjustment), or a whole session's worth of adjustments (say 2 hours of work).

The only workaround for this is to close CO7 periodically. When it restarts, it puts be back in my session at some random location, not where I left off.

This is basically the same behavior as case #108099.

I just don't want to lose all the work I've done in customizing my workspace. It has a lot of settings I rely on for clients. I've been living with this behavior for months, and lost hours and hours of work accidentally.

There's got to be a single file I can delete and re-start CO7 to get back to work...
TTFN
GRegg

13件のコメント

Paul Steunebrink

2013年07月15日 02:18
Have you created a support case already on this? You were referring to a case number. If so add this info to it.
0
Gregg Le Blanc

2013年07月15日 05:25
I can do that, however for the symptoms I am having, they will tell me to follow the procedure I have liked to already.

When I do that, I will lose all the customizations I have made to Capture One.

I do not want this to happen.

I have asked support previously if this was possible to avoid. But was not answered directly, however, I am wondering if someone in the community here (perhaps one who uses multiple computers) can save / export / restore their Capture One workspace layout, recipes, etc.

So, I know the remedy for this "undo" problem... - it's totally uninstall and destroy any evidence CO7 was on my PC... But I always lose something (like output naming conventions etc.) each time I have to do this.

Hope that makes sense...
0
Paul Topol

2013年07月15日 23:10
Hi,
You do know that all your changes and settings for each file go into a sub-directory of the pics you are working on called "CaptureOne"? e.g. Y:\2012\01-Jan-20_Israel\RAW\CaptureOne

If you mistakenly delete that directory then all your work has gone. Backup this directory and you still have the changes/settings.

There is also a way of packing all this info together with each pic into its own file so you can move it complete to another directory/computer, etc.
You can also change the shortcut keystrokes for almost every action. So, perhaps, get rid of the Ctrl-Z shortcut for yourself.

Hope some of this helps
Have a great day
Paul
0
Gregg Le Blanc

2013年07月15日 23:32
True, that's a good error-prone workaround to preventing lots of work-loss due to a single Undo issues.
(And actually, CO7.1.x doesn't recognize some special ThinkPad keys on my keyboard that CO7.0.x did - I filed that bug a while ago)

One of my SessionDB's was evidently corrupt, so I killed it, and created a new one - and yes, the edits etc. were all preserved.

However, Capture One's behavior is unchanged from session-to-session. The central storage of information about its data is definitely busted / hosed. So, the edits to pictures are OK (unless I use Undo like a bonehead), and I can move edits from PC to PC.

But it looks like I really need to do this "clean / complete uninstall" now.
Which destroys all my CO7 workspace customizations...

That's the stuff I'd like to take with me from one PC to another, or at least between disk upgrades / uninstalls / PC changes.

Thanks for the help! I have been backing up these sessions more frequently as the performance and behavior has become more unruly.

Currently, when I'm switching between images, it may take 10-20 seconds and the CPU will be 30-40%, and it consumes 4-5GB of RAM.

When I did a database check on that session it was having problems with "variants" I had deleted (that's when I deleted the COSessionDB for that session).

Anyway, I filed a new support case asking if I could preserve my "Profile Settings" information prior to wiping CO7.
We'll see what happens.
0
Gregg Le Blanc

2013年07月16日 13:46
Yay!
They have updated the knowledge base article to include the location of the preferences information!

It is at the bottom of the old article here (updated yesterday):

Thanks Phase One!
Time to uninstall and get working right again!
😄
0
Gregg Le Blanc

2013年07月20日 04:06
An update:

"Preference file locations" for CO7 are actually in 2 places:

The KB article shows the path to the "user.config" which is the "current state of Capture One" when you closed it last.

That's useful, but not what I'm interested in.

It is located here:
C:\Users\<user>\AppData\Local\Phase_One\CaptureOne.exe<long StrongName text>\<Current Version Number>\user.config

That records "what CO7 looks like when you quit" but not "how your workspace is configured".

THOSE files are actually located here... very neatly organized!
C:\Users\<user>\AppData\Local\CaptureOne

Take a copy of everything in there, back it up.
If you would like to "sync" your Workspace (recipes, etc.) across machines, you should (in theory) make the following folders consistent between each user / machine.
To do this, you would use a tool like:
or some other tool that can operate on folders "in place" (so not Dropbox, SkyDrive, etc. where you have to copy folders to a central location).

And you'd want to do it via Peer to Peer (non-cloud) sync on a schedule.

And you would do that with Capture One CLOSED.

Now, the next thing - instead of Uninstalling / Reinstalling CO7 to speed it back up, I looked at the "Batch70" folder.
This has a subfolder named "history" that is FULL of basically "undo" information (I suppose) for many sessions.
So I backed all that up to another folder, nuked the copy that was in place, and also nuked the session file listed in the Capture One KB article:
(which could have been corrupt - it will get re-made if needed)

Once I removed the contents of the Batch70\history folder (not the folder), Capture One returned to its previous speed for my troubled session (which was taking 5-15 MINUTES to select multiple photos - now that operation is instantaneous).

We'll see if my Undo is fixed too.

If this lasts, I've solved 2 problems - making CO7 return to its original speed & also preserve my run-time preferences if I change machines!

Hope that helps somebody.
TTFN
Gregg
0
Paul Steunebrink

2013年07月20日 08:21
See also
http://www.phaseone.com/en/search/artic ... nguageID=1
for similar instructions.
0
Gregg Le Blanc

2013年07月20日 15:45
Except that article doesn't tell you the files in the Capture One folder are the actual Preferences files.

Not the one listed at the bottom of the KB entry.

If you preserved that one file, you would not save your custom Crop settings, Output Recipes, Workspace layout... Etc.

I guess I'm the only person who wants to do that?

I was trying to help anyone who would want to preserve their workspace, and sync that across computers.

That article, which I did reference and use, does not contain that information.

Which is why I am augmenting it here for the curious.
I hope it helps someone rather than wasting their time.
Thanks!
0
Paul Steunebrink

2013年07月20日 19:57
For the record, you did an outstanding job with your detailed post. The question where the appdata resides comes up here regularly.
0
Gregg Le Blanc

2013年07月20日 20:46
OK, cool... I wasn't sure.

I feel like I should re-title the post now.

I believe the "fix" so far (deleting the "Batch70\history" folder contents) has corrected it the original "Undo" behavior for me. But other issues remain.

I would recommend following the Support knowledge base article is the best procedure (and now you can back up those folders that contain interesting preferences for your environment to help you get back to work - or sync them to another machine).

My other issue is the one session that corrupts its .cosessiondb file continually (due to "No fix for: Layer with both Owner and variant" when I check it). Repairing / Deleting and re-making the session doesn't help. It doesn't tell me which image it is.

So I may end up following the entire uninstall / reinstall anyway!
At some point I will process some photos! 😄
0
SFA

2013年07月21日 03:08
Gregg,

This error you have

"No fix for: Layer with both Owner and variant"

Can you tell us a little more about that?

A few weeks back I had a problem with a session that seemed to stop responding when simply scrolling from one image to the next in the browser strip. No idea why and could not seem to fix the problem.

Then spotted a bad preview in the session. Tried to regenerate it but it would not work so I guessed the .cos file had a problem. Deleted that and made a new edit for that one image and the whole session started to work correctly once again.

So .... I am guessing that for whatever reason the .cos file became corrupt the result was a corruption or disruption of the links between all the files involved and that is, presumably, the function of the cosession file. It maybe that the .cos fiel was not actually corrupt - just the database links - but whatever the reason deleting the files, and therefore the links, resolved the problem.

The error message you mention sort of suggests that there may be something similar happening in your session but with a local adjustments file? But I'm making a guess about the use of terminology here so I'm not at all certain.

Do you use local adjustments?

Grant Perkins
0
Gregg Le Blanc

2013年07月21日 16:37
Hi Grant!
You may have the same issue as I do... I don't know how it started, but my issue definitely "survives" deleting / creating my "cosessiondb" file.

I see the following error below by clicking:
File / Check Document / <and then allow it to close / open the cosessiondb file>

The Repair step won't work on this particular session - but has worked on one other session.

[quote="SFA" wrote:

This error you have

"No fix for: Layer with both Owner and variant"

So the database "check fails" and then you can sometimes click "Repair" on it (if you click in the window that appears and scroll around). The repair usually fails.

When I've gotten it to succeed, it's usually false... (just try re-verifying)

The trouble is, I have a lot of variants in this "session". And a couple of these variants may have Local Adjustments.
The error I have doesn't say which file is failing.

When the session "slows down" - excruciatingly so - I delete the cosessiondb and create a new one.

[quote="SFA" wrote:

A few weeks back I had a problem with a session that seemed to stop responding when simply scrolling from one image to the next in the browser strip. No idea why and could not seem to fix the problem.

Then spotted a bad preview in the session. Tried to regenerate it but it would not work so I guessed the .cos file had a problem. Deleted that and made a new edit for that one image and the whole session started to work correctly once again.

So, I think we're in the same place... If I multi-selected files, CO7 would grind to a halt. Or even try copying adjustments.

I guess I could go delete the COS files for all the ones that have variants?
Seems strange. But maybe that's it... from the behavior we're seeing.

I also notice that the Metadata that is written out for the JPG's I write from these sessions shows up in Windows as, say 3 stars (not true), but in other tools as 4 stars (what I chose in CO7 and I did the "Sync Metadata" step in CO7, and the "Include Rating and Color Tag" is in my output recipe).

I wonder if there is a filesystem problem somewhere too that's causing write issues (i.e. COS files, cosessiondb, weird metadata writing...)? I don't like that thought...
0
SFA

2013年07月21日 17:15
Hi Gregg,

The problem I described has only happened once to me. I suspect that something maladjusted some pointers in the cosession database. I don't really know what but it was around the time that I inadvertently deleted (to Trash) a file that I subesequently undeleted - which process seemed a bit odd at the time. However there is no way I can readily link the two. I don't plan to delete and re-instate images frquently!

You may want to check the Settings70 folders (one for each image folder referenced in the Session) and look for "comask" files. They hold the information about local adjustments. If there are not many it might be wrth experimenting by moving them (one folder at a time?) elsewhere (rename the extension might work too?) and then re-build the session database to see if it makes any difference or even just gives a different error message or error message pattern.

(Actually a good SQL analysis of the DB might be a better way but without knowing the structure and what to look foor that could be a challenge too far.)

With my problem an obviously corrupt preview in the browser was still corrupt after re-generation. It had no obvious link to the places where I found the problems when browsing but then the internal data storage withing the db would not be concerned about that sort of relationship.

As I recall I probably used Reset on my bad preview file to remove the .cos file and create a new one. Simply deleting it might not entirely fix internal although anything that sets out to repair a db should do - but I didn't need to do that as far as I can remember.

I might be barking up the wrong tree here but it you only have a few comask files it should not be too difficult to check the effects of making them unavailable. Then see what comes up after that and decide what to do next

It occurs to me that you could copy the entire session to a test session, remove the loc adjustments in the test session and see if that fixes things.

If so, copy the session again and then remove the local adjustments one by one to see which one(s) are problematic. Then compare the bad file to a good file to see if there are any obvious structural differences - or maybe just send to Phase One wher the experts should have a better idea about rapid analysis.

Of course all of this may have no effect at all .... and I might be on completely the wrong path for your problem.

Grant Perkins
0

投稿コメントは受け付けていません。