Bug 122095 - LibreOffice hangs periodically for a few seconds with remotely opened documents
Summary: LibreOffice hangs periodically for a few seconds with remotely opened documents
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: filters and storage (show other bugs)
Version:
(earliest affected)
6.3.0.0.alpha0+
Hardware: All All
: medium enhancement
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: Network
  Show dependency treegraph
 
Reported: 2018-12-14 11:47 UTC by Heiko Tietze
Modified: 2024-05-27 10:17 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Heiko Tietze 2018-12-14 11:47:27 UTC
The feature to save/edit a document remotely (File > Open Remote...) has the major issue that it hangs frequently for a few seconds, apparently due to autosaving the temp files. So the idea is to store temp files locally, or just disable it for remote operations.
Comment 1 m_a_riosv 2018-12-14 13:37:19 UTC
Hi Heiko, I think the only file saved in remote should be the lock file, temp files should be saved in the path that is options, auto-saved files if I'm not wrong are saved in the backup folder inside the user profile.

If the lock file it's no saved in remote, then the same file could be opened and saved for more than one without notice, and it can not be shared either, what maybe be it's important for companies.
Comment 2 Heiko Tietze 2018-12-14 13:44:15 UTC
I might be wrong with the temp file but whatever it causes LibreOffice hangs for a few seconds with files opened from TDF's Nextcloud.
Comment 3 m_a_riosv 2018-12-14 15:54:09 UTC
I see also a few second from tdf next cloud, but I can't see there is created a lock file when is activated edit mode, anyway I'm not sure if there is a speed limitation, usually I can't download more than around 400 KB/sec from tdf sources.
Comment 4 Xisco Faulí 2019-01-17 12:20:34 UTC
Hello Heiko,
is this issue still reproducible in recent master build ?
Comment 5 Heiko Tietze 2019-01-17 15:54:39 UTC
(In reply to Xisco Faulí from comment #4)
> is this issue still reproducible in recent master build ?

Yes, it is still an issue.
Comment 6 Xisco Faulí 2019-06-27 13:44:45 UTC
(In reply to m.a.riosv from comment #3)
> I see also a few second from tdf next cloud, but I can't see there is
> created a lock file when is activated edit mode, anyway I'm not sure if
> there is a speed limitation, usually I can't download more than around 400
> KB/sec from tdf sources.

Moving to NEW then...

@Mike, I thought you might be interested in this issue!
Comment 7 Stéphane Guillou (stragu) 2024-05-27 01:16:07 UTC
Heiko, don't you think this is essentially the same issue as bug 48416?
Comment 8 Heiko Tietze 2024-05-27 08:54:08 UTC
(In reply to Stéphane Guillou (stragu) from comment #7)
> Heiko, don't you think this is essentially the same issue as bug 48416?
Sounds reasonable.

*** This bug has been marked as a duplicate of bug 48416 ***
Comment 9 Mike Kaganski 2024-05-27 09:01:51 UTC
(In reply to Stéphane Guillou (stragu) from comment #7)
> Heiko, don't you think this is essentially the same issue as bug 48416?

I disagree.
The bug 48416 is about making the save async. That is a separate, useful, and unlikely-to-happen-soon thing.

This one is orthogonal. It is about *something unneeded* happening when autosaving a remote file; it *seems* to communicate with the remote side, when it *seems* to have everything locally already (when opened it), and it needs to *save* the recovery information only locally.
Comment 10 Heiko Tietze 2024-05-27 09:46:53 UTC
(In reply to Mike Kaganski from comment #9)
> I disagree.
Solving bug 48416 would also fix this issue. Or do you think there is something else we can do?
Comment 11 Mike Kaganski 2024-05-27 09:58:18 UTC
(In reply to Heiko Tietze from comment #10)
> Solving bug 48416 would also fix this issue.

Solving bug 48416 would simply *hide* this issue. It would continue to do something unneeded (and maybe even problematic), the task that should be eliminated, but the user wouldn't see that, because it would happen in the background. Making some unneeded behavior unnoticed doesn't make it unneeded.
Comment 12 Mike Kaganski 2024-05-27 09:59:01 UTC
(In reply to Mike Kaganski from comment #11)
> Making some unneeded behavior unnoticed doesn't make it unneeded.

Err. I meant: Making some unneeded behavior unnoticed doesn't make it needed.