Hi, after installing LibreOffice v4.1.0 or v4.0.5 on two different Windows 7 (x64) machines on both systems ooofilt_x64.dll causes permanent high CPU load via SearchFilterHost.exe and the indexing service does not finish indexing. Unselecting all OpenDocument file types in indexing service preferences fixes the problem. As the bug is not resent in all versions before 4.0.5 reverting back to LibreOffice v4.0.4 also solves the problem. Regards, Volko
I can confirm this error SearchFilterHost.exe running on three cores about 50% CPU usage all time In C:\Program Files (x86)\LibreOffice 4\program\shlxthdl I changed files ooofilt.dll and ooofilt_x64.dll to those from version 3.6.4.3 then problem disappeared
*** Bug 68490 has been marked as a duplicate of this bug. ***
Confirmed by comment 2 & Bug 68490. Also Bug 55854 might be related, although it's reported against 3.6.2.2.
According to Bug 56035 there are some changes related to indexing in 4.1.1. Would be great if someone could test it, and report here. thanks.
I installed the 4.1.1.2 (release candidate) to see if this was fixed. Unfortunately, Microsoft Windows Search Filter runs long and at high cpu. I had uninstalled LibreOffice, rebuilt the search index, and it took less than an hour. I then installed LibreOffice 4.1.1.2, and while indexing was finding OpenDocument files, it was taking upwards of 10 hours, and indexing was still running. I then uninstalled the Windows Explorer extensions from LibreOffice and rebuilt the index--this took a little over a half-hour for 8955 files. Unfortunately, Windows Search indexing makes no information about what specific files it's working on apparent, so I can't really tell what's going on. If you'd like help in debug, I'd be happy to help.
Hi. I had the same problem while creating a text document (LibreOffice 4.1.0.4 + Win7 x64) on drive C:, in the folder "My Documents". The document included a 32-bit PNG image (509kb) stored on drive E: which is not indexed by Windows Search Filter Host. It took about 1 minute to save the ODT file. Then I changed the picture in the ODT to the same in 8 bits (same folder on E:, not indexed). The saving was instantaneous, even if the ODT was stored in a place checked by Windows Search Filter Host (e.g. "My Documents"). I also tried to save the document with the 32 bits PNG image in a folder which is _not_ indexed by Windows and it saved it instantly ! Might it be due to the .~lock file ? Does WSFH tries to open the file in read+write mode while the .~lock file is present, causing a latency ? I preferred to stop Windows' file indexation for the moment. Good luck for solving this case.
Bug confirmed with 4.1.1.2 version on two Win8 machines. Full core CPU usage starts when windows search host tries to index open document file.
Same here, constant 40% CPU load, had to remove explorer extensions.
Can confirm this for 4.1.0 and 4.1.1 (and 4.0.5) also on 32-bit Windows 7. Using Process Explorer I saw SearchFilterHost.exe using high CPU (>= 1 core of my X4) when searching certain odt or odp files. In addition, Windows Search tries to index these files several times and obviously always fails. All these files have pictures embedded - that's the only thing I could find they have in common.
Problematic behaviour is still there in version 4.1.2.2. The only way to circumvent the bug (other than disabling the indexer) is replacing the files in <installdir>\program\shlxthdl with the versions from AOO 4.0.0 (or some version of LO prior to 3.6) - or installing MS Filterpack 2.0 and let their filters index OpenDocument files. Note: it seems that my odt and odp files causing high cpu with ooofilt from LO 4.1.x are silently skipped by AOOO 4.0.0 ooofilt (without throwing an error in Windows' eventlog), only MS' filters index them correctly.
I can confirm this bug for LibreOffice 4.1.3.2, on 64-bits Windows 8.1. It loads one of the CPU cores 100%, thus reducing battery life of my notebook. I think importance should be changed to high.
I think it's a duplicate of Bug 56035 Please test with 4.1.4 RC1 (or 4.2.0 beta1): http://www.libreoffice.org/download/pre-releases/
(In reply to comment #13) >(or 4.2.0 beta1) Note that for 4.2.0 beta1, you should install from the command line with: msiexec /i <downloaded file>.msi WRITE_REGISTRY=1 Otherwise the test is irrelevant. (Beware: It will overwrite file associations of currently installed version.)
This bug is fixed for me (Windows 7 Professional 64-bit) with LibreOffice version 4.1.4.2.
Had this problem on 32-bit Windows 7, and for me, too, this seems to be solved in 4.1.4.2 (didn't try 4.2 yet). Thanks!
Confirm that this bug is fixed for me (Windows 7 Professional 64-bit) with LibreOffice version 4.1.4.2 as well. Thanks for fixing the bug.
I also find that this is now working in LibreOffice 4.1.4.2 running on Windows 8.1. Thank you for fixing this!