Description: Currently, saving the information for autorecovery paralyzes all other activity in LO. For a 1 MB Writer document, the process takes half a minute, so if the saving interval is put to 10 minutes, the user is forced to turn thumbs for 5% of the time working on the document. This is because the process does not run in the background. It could be improved by using more than one thread in running LO. Steps to Reproduce: Set autorecovery to every 10 minutes. Actual Results: Every 10 minutes LO interrupts your work flow. Expected Results: The saving should run in the background without affecting the user. Reproducible: Always User Profile Reset: No OpenGL enabled: Yes Additional Info: There is also a bug which is a consequence of the principal problem: I hit a key, and before the associated operation can be executed, the moment for autorecovery has come. This now paralyzes all actions, and finally the action required by the key hit before is forgotten. I.e., autorecovery wipes out actions started, but not completed at its own start.
Sounds to me like a duplicate of bug 48416. What do you think?
It depends on how narrow the requirements for a duplicate are: The current bug is about the autosave process which is a precondition for autorecovery. Bug 48416 is about a save operation triggered by the user. However, the technical process - a save operation on the file - is almost the same. And certainly the consequences for the user are the same, viz. the complete paralysis of the application. Anyway, it is interesting to note that a complaint about this behavior of LO has been around for years. It might be worth promoting the request for a multi-threaded design a bit. (The solution suggested by the reporter of #48416 seems insufficient.)
(In reply to Christian Lehmann from comment #2) > It depends on how narrow the requirements for a duplicate are: > The current bug is about the autosave process which is a precondition for > autorecovery. > Bug 48416 is about a save operation triggered by the user. Yes, you're right, so perhaps bug 48416 doesn't fit with a meta bug Auto-Save-Auto-Recovery. So I agree, that it is not a duplicate.
Since bug 48416 is an accepted enhancement, let move this one to NEW as well...
(In reply to Dieter Praas from comment #3) > (In reply to Christian Lehmann from comment #2) > > It depends on how narrow the requirements for a duplicate are: > > The current bug is about the autosave process which is a precondition for > > autorecovery. > > Bug 48416 is about a save operation triggered by the user. > > Yes, you're right, so perhaps bug 48416 doesn't fit with a meta bug > Auto-Save-Auto-Recovery. So I agree, that it is not a duplicate. I don't understand. Bug 48416 is about not blocking the UI while saving & autosaving. Contrary to what is claimed, it is *not* solely about a user-triggered save operation. Christian: please explain, how your request is different from bug 48416 in concrete terms.
I am not quite sure what the dispute is about. Both the original author of bug 48416 and one of the later contributors refer explicitly and exclusively to pressing CTRL-s and never mention AutoSave. However, whoever entered the specification of the classificatory item 'Blocks' wrote: AutoSave-AutoRecovery-Backup. I am ignorant of its origin, meaning or function. Bug 122724, instead, refers explicitly to the AutoSave operation initiated automatically by LO at a fixed interval. Again, the rubric 'Blocks' says: AutoSave-AutoRecovery-Backup. It seems quite possible to me that technically, the Save operation executed is the same in both cases. However, it is not the duty of the user who files a bug to know such things. Thus, if fixing one of these bugs means fixing the other one, too, then please merge these two bugs into one.
*** This bug has been marked as a duplicate of bug 48416 ***