File preview blocks any other operation in the file explorer during several seconds. This occurs everytime a LibreOffice document is selected, no other operation (like opening the document or selecting another file for example) can be done until the preview is displayed. Happens only with open document format.
I can confirm this bug. In my case Explorer is hanging several minutes not only seconds. (Windows XP, LO 3.6.0.4) This bug might be related to: https://bugs.freedesktop.org/show_bug.cgi?id=53420 https://bugs.freedesktop.org/show_bug.cgi?id=53533 https://bugs.freedesktop.org/show_bug.cgi?id=52078
I also confirm. It’s related to the explorer extension. Unselect it at installation and it should work properly again. Explorer extension is very slow on Windows and may crash the explorer if you select a big file (several Mb).
I can confirm this bug on my two computers (seven, x64) on my notebook, explorer process take over 100 % of cpu usage, and the two cores are working at 100 % thus the computer is unusable on my desktop computer, explorer process is at 50 % and only two of the four cores are working at 100 %, so the computer is still usable. the cpu usage stops only when restarting the computer or killing explorer process imho, most user on windows have a quad core, and so the bug could stay hidden. the computer, is slow but usable, and you can't delete come file but no more afaiks pierre
I confirm and add another consequence: It is not possible any more to rename an ODF file by using windows explorer (on Vista and seven)
(In reply to comment #4) > I confirm and add another consequence: > It is not possible any more to rename an ODF file by using windows explorer > (on Vista and seven) Sorry, I forgot to mention that this happens only on large files (ie 9 Mo)
According to this page (http://wiki.documentfoundation.org/Release_Criteria), this bug is a blocker, as it may freeze or crash the Windows explorer.
*** Bug 54249 has been marked as a duplicate of this bug. ***
Seems to be a duplicate of bug 53533 which is fixed in LO 3.6.2.0+ Fridrich: please, can you confirm ?
OK, it might have been fixes as the bug #53533. Could anyone try to verify it using the daily build from http://dev-builds.libreoffice.org/daily/Win-x86_9-Voreppe/libreoffice-3-6/current/ ? I agree that it is very annoying and we need to fix it ASAP. On the other hand, there exists a workaround to do not install the extension => it can't block the next release => lowering the severity a bit
According to my tests, the patch below increases speed of search times dramatically. I set this bug as RESOLVED FIXED, please reopen, if you still experience slowdowns.
I don't know what's wrong with the bot, FYI this is the commit: http://cgit.freedesktop.org/libreoffice/core/commit/?id=ed08ddb31ba37da393a42586cbaa4c19e771598c
Re-tested with LibreOffice 3.6.2 + win XP, still have the problem with .odp files. Blocks the explorer on network drives, extremely slow on local drives. Seems to work file with writer & calc files.
(In reply to comment #12) > Re-tested with LibreOffice 3.6.2 + win XP, still have the problem with .odp > files. Could you please attach a few sample documents, or if they too large upload them somewhere (e.g. to Dropbox)? It is fast with our test documents. Thanks!
Created attachment 68120 [details] Test document for preview
I think I was mistaken by the version number, it probably was 3.6.0.2 on my PC at the time I reopened the bug since it doesn't block the explorer for a very long time anymore. I'll be more careful about that next time. I added a test document, it blocks the file explorer for about 3 seconds with v3.6.2 if I try to preview it on a network drive, which not very fast but acceptable. It's rendered instantly on a local drive, so it's not the processing time that seems to matter. The preview seems to generate a huge number of requests to the file server during those 3 seconds, that could explain the delay. Eric Ficheux
Fair enough. I mark this RESOLVED FIXED again. Just FYI, for the preview we need to find the thumbnail image in the document, which is a zip archive. Reading zip was significantly accelerated in 3.6.2, because the program now looks for the central zip directory in the last 1024 bytes of the file instead of reading the whole file.
Proposal for improvements: #56007