I've been hit by this for quite some time now - I cannot recall if this was introduced with LO4 or if this has been the case in earlier releases as well. The situation is this: On my Mac, when I have a network drive mounted through a slow VPN connection, LO Writer (but possibly others as well) hangs for an amount of time depending on the network speed upon simple user interactions, like adding a line break into a document. This can be reproduced even if that document being edited is not saved yet - so basically there is nothing that should cause LO to access the network drive. Nevertheless it does - the problem just disappears when the network drive is unmounted. Looking at some I/O-Profiling I did I can see that LO attempts to access a huge number of files on the network drive that I had open in the past. Seeing all those reads it is quite obvious that this will be slow. The question is - what does it try to do on the network drive? Neither of those documents is opened currently. And why does it do this upon simple user interactions. I could see this activity on my Mac with the Instruments/File Activity tool. Unfortunately the trace contains some confidential information, so I cannot share it. But I believe it would be reproducible easily.
Would it be possible you give the complete url of some files so it could shed some lights on the problem? Indeed, I suppose that not all the files are confidential, above all just their file name!
Of course, for example /Volume/work/Rechnungen/3K-2014-065.odt This is a file I had open last week. /Volumes/work/Angebote/time-and-material.odt Another file I had open some time this week. /Volumes/work is the mount point of the network share. If needed I can provide more file names,I just cannot attach the full dump.
In this tool (Instruments/Files on osx) I just see file/dir operations. And all I see there is paths, no URLs. If you tell me how to capture what you are looking for I am more than happy to provide this.
If you clear your recent document list, does it work faster?
Clearing the history resolves the problem until a document from that network share is opened. Then I again see a lag when doing simple operations in another document that is not yet saved. Though not nearly as bad as it was initially when the recent documents list was full of documents from that share (which happens to be the main share I store documents on). So it seems that it is actually the recent document list that is causing the problem.
In Windows, I don't detect any file activity on the members of the recent document list while I am editing the document.
This is virtually impossible to test reproduce for most people. I have remote AFS mounts, but they are on the same LAN, and I've not noted any particular slowdown, granted this is not the same setup as that described.
You can simulate a slow network with the "Network Link Conditioner" that is part of Xcode: https://developer.apple.com/library/ios/documentation/NetworkingInternetWeb/Conceptual/NetworkingOverview/WhyNetworkingIsHard/WhyNetworkingIsHard.html This might help to reproduce the issue.
I have also been hit by this. A theory I saw is that Libreoffice periodically does a QUERY_PATH_INFO through SMB requests. Link to the ask.libreoffice.org question: http://ask.libreoffice.org/en/question/36992/libreoffice-periodically-accesses-files-in-recent-list-causing-freezes/
Have tried some more now, and in my case it is completely related. If I clear my history and reopens the document from the share(therefore having only one item in the recent list), the periodical freezing is very short, perhaps a second or two. But if I then clear the list completely, all freezing goes away and LO becomes as responsive as one would expect. And this while editing a document I have on the network share(so *that's* not related). So I would agree with previous reporters that this is related to the recent-list.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.