Description: I've been using LibreOffice for many years, and never really had a problem - until now. I'm running LibreOffice 7.2 (7.2.2, via Ubuntu package 1:7.2.2_rc2-0ubuntu0.20.04.1~lo1, to be precise) and it's taking a long time to load - seeming to hang on file operations. Previously, I'd load Writer and it'd flash the splash screen for a split second and load within a second or two total. Now, even when opening Writer with a blank template it's taking anything up to ten seconds to load - and the same is true for all the other LibreOffice apps. If I load a saved Draw document, for example, the Draw window comes up almost instantly - but pauses with "Loading document" in the status bar for a full eight seconds. Same for existing Writer files, Calc files, and so on. Oddly, I can fix the problem easily: resetting my user profile completely. When I do that, all LibreOffice apps load like they used to - in under a second. Unfortunately, after a few days - even if I make absolutely no changes to LibreOffice's settings - it's back to loading slowly again, until I reset the user profile once more. Steps to Reproduce: 1. Install LibreOffice 7.2.2.2 in Ubuntu 20.04.1 from the LibreOffice Fresh PPA, using a clean user profile. 2. Use it for a few days. 3. Yes, I know these reproduction steps are vague, I apologise for that! Actual Results: At some point within a few days, LibreOffice will take up to ten seconds to load files - even the blank default templates. Expected Results: LibreOffice loads in under a second. Reproducible: Always User Profile Reset: Yes OpenGL enabled: Yes Additional Info: Kernel 5.4, 16 CPU threads, LibreOffice installed on a high-end SSD, threaded Calc, OpenCL disabled, all settings at their defaults. Genuinely at my wits end on what's causing it, I'll be honest!
Not reproducible for me with LO 7.1, 7.2 and current master, all built at home under Ubuntu 20.04. Two suggestions: 1/ file a bugreport against Ubuntu on https://bugs.launchpad.net 2/ try the LibreOffice build from LibreOffice project: https://www.libreoffice.org/download/download/ to see if the problem is not specific to the Ubuntu build. Status has been set to NEEDINFO, please set it back to UNCONFIRMED once requested information has been provided. Best regards. JBF
Let's assume duplicate. *** This bug has been marked as a duplicate of bug 144612 ***
Set back to UNCONFIRMED per my comment in https://bugs.documentfoundation.org/show_bug.cgi?id=144612#c7. Actually I encountered the same issue with master build some days ago. I reset the user profile and it became fast again, so I thought it was due to corrupted user profile. But I am not sure the steps to reproduce this.
Since posting this bug, I have had to reset the user profile several times to restore performance. As of the last reset, I changed absolutely nothing in the profile - not even adding my name in there. It did not make a difference: after a while, LibreOffice was back to taking ten or more seconds to open.
Could this be because you have lots of fonts on your system? Do you still see this with the latest LibreOffice version? Please copy and paste here the contents of your Help - About. This allows us to know more about your system. Set to NEEDINFO. Change back to UNCONFIRMED after you have provided the information.
(In reply to Buovjaga from comment #5) > Could this be because you have lots of fonts on your system? > > Do you still see this with the latest LibreOffice version? > > Please copy and paste here the contents of your Help - About. This allows us > to know more about your system. > > Set to NEEDINFO. > Change back to UNCONFIRMED after you have provided the information. Files are slow for me to open as well and I've isolated why, and I don't believe it's the fonts. I've 97 fonts in my system, totaling 362 items in the Windows/Fonts folder. I turn the printer on, all files load fine. LibreOffice needs to not poll the printer when loading files.
Version: 7.5.0.2 (X86_64) / LibreOffice Community Build ID: c0dd1bc3f1a385d110b88e26ece634da94921f58 CPU threads: 8; OS: Windows 10.0 Build 19045; UI render: Skia/Raster; VCL: win Locale: en-US (en_US); UI: en-US Calc: CL threaded
(In reply to xordevoreaux from comment #6) > Files are slow for me to open as well and I've isolated why, and I don't > believe it's the fonts. > > I've 97 fonts in my system, totaling 362 items in the Windows/Fonts folder. > > I turn the printer on, all files load fine. > > LibreOffice needs to not poll the printer when loading files. That would be bug 42673, which is said to be Windows-only, although there is one person commenting that it happens on Linux as well.
Dear Gareth Halfacree, This bug has been in NEEDINFO status with no change for at least 6 months. Please provide the requested information as soon as possible and mark the bug as UNCONFIRMED. Due to regular bug tracker maintenance, if the bug is still in NEEDINFO status with no change in 30 days the QA team will close the bug as INSUFFICIENTDATA due to lack of needed information. For more information about our NEEDINFO policy please read the wiki located here: https://wiki.documentfoundation.org/QA/Bugzilla/Fields/Status/NEEDINFO If you have already provided the requested information, please mark the bug as UNCONFIRMED so that the QA team knows that the bug is ready to be confirmed. Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-NeedInfo-Ping
Dear Gareth Halfacree, Please read this message in its entirety before proceeding. Your bug report is being closed as INSUFFICIENTDATA due to inactivity and a lack of information which is needed in order to accurately reproduce and confirm the problem. We encourage you to retest your bug against the latest release. If the issue is still present in the latest stable release, we need the following information (please ignore any that you've already provided): a) Provide details of your system including your operating system and the latest version of LibreOffice that you have confirmed the bug to be present b) Provide easy to reproduce steps – the simpler the better c) Provide any test case(s) which will help us confirm the problem d) Provide screenshots of the problem if you think it might help e) Read all comments and provide any requested information Once all of this is done, please set the bug back to UNCONFIRMED and we will attempt to reproduce the issue. Please do not: a) respond via email b) update the version field in the bug or any of the other details on the top section of our bug tracker Warm Regards, QA Team MassPing-NeedInfo-FollowUp