Hi all, 
I have exactly the same misbehaviour with LibreOffice Version 3.6.2.2 (Build ID: da8c1e6). Contents in LibreOffice Writer or LibreOffice SpreadSheet files are no longer indexed and cannot be retrieved under Windows 7 64-bit. I have checked that the file types are correctly set up in the indexing options. This is going to force me to ge back to an older version. Does anyone know which version still works? I am personally quite sad at seeing new features come out when fundamental features get broken.
Orlando.

I went back to version 3.4.6 and now I have all of my files indexed correctly.

(In reply to comment #1)
> Hi all, 
> I have exactly the same misbehaviour with LibreOffice Version 3.6.2.2 (Build
> ID: da8c1e6). Contents in LibreOffice Writer or LibreOffice SpreadSheet
> files are no longer indexed and cannot be retrieved under Windows 7 64-bit.
> I have checked that the file types are correctly set up in the indexing
> options. This is going to force me to ge back to an older version. Does
> anyone know which version still works? I am personally quite sad at seeing
> new features come out when fundamental features get broken.
> Orlando.

Hello Tea,

Indexing the contents of LibreOffice files with Windows 7 used to work for me when I had LO version 3.4 too and I am glad that going back to an older version fixed the Windows 7 search issue for your LibreOffice files. This confirms that it is a real bug in the later LibreOfffice releases. Old versions of LibreOffice are not available for download from libreoffice.org and I was unable to locate an English version of LibreOffice 3.4.6 there, I only found 3.4.5 somewhere else and I'm hesitant to install that. I therefore downloaded the very latest version 3.6.3.2 and installed it after removing 3.6.2.2 and deleting the LO profile. However, version 3.6.3.2 does not fix this search issue and the contents of LibreOffice documents (I tried ODT and ODS files) are still not indexed by Windows 7 (64-bit). If I can locate an official download site for version 3.4.6 I will go back too, I use the search capability of Windwos 7 very often. I wonder why this bug is still listed as "unconfirmed".

I believe I have had this problem since installing OpenOffice.org 3.4 (I have 3.4.1 installed).  I installed LibreOffice 3.6 (3.6.4.3) without uninstalling OOo.

I have rebuilt search, also ticking "Always search file names and contents" in Explorer>Organize>Folder and Search Options>Search.

Agent Ransack will search inside ODS and ODT  just fine (though it would not when I installed the Microsoft Office Filter Pack until I uninstalled it and repaired LibreOffice).

But Windows Search still finds nothing.   I'm on Windows 7 Home Premium, which is a 64-bit system.  

By searching through the registry I have confirmed that the IFilter in use is the LibreOffice 64 bit one.

See also
http://forum.openoffice.org/en/forum/viewtopic.php?f=15&t=55483

Also discussed here:

http://comments.gmane.org/gmane.comp.documentfoundation.libreoffice.user/24743

Turned out the issue at OpenOffice was different.  After Apache took over they had neglected to put in a 64 bit filter.  I uninstalled OOo 3.4 and reinstalled 3.3 and now Windows Search can see inside my files, even the ones I created with LibreOffice.  

If anyone wants a copy of the OOo 3.3 version of the 64 bit filter files, I can send them to you for comparison with the current LO versions and the upcoming Beta LO versions, neither of which worked for me.

Same problem here:

Environment: Windows 7 SP1 X64, LibreOffice 3.6.4.3

contents of OpenDocument files are not indexed (everything else is working without any problem, e.g. .pdf, .doc, .txt ...). Is LOdev4.0Beta2 solving this show stopper?

I don't know.  The Beta I had a few weeks ago installed totally separately to the main installation of 3.6, so you could easily install it, and copy the relevant filter files to the corresponding directory for 3.6 (having previously backed up or renamed the existing ones).

Unfortunately still no solution with LOdev 4.0Beta2:

Having replaced the filter files from LOdev 4.0Beta2 into LO3.6:
=================================================================
ifilter settings BEFORE file replacement:

ooofilt_x64.dll	OpenDocument Format Filter	3.6.4.3	3.6.4.3	The Document Foundation	C:\Program Files (x86)\LibreOffice 3.6\program\shlxthdl\ooofilt_x64.dll	{7BC0E713-5703-45BE-A29D-5D46D8B39262}	{7BC0E710-5703-45BE-A29D-5D46D8B39262}	23.12.2012 02:46:26	



Copying 
C:\Program Files (x86)\LOdev 4.0\program\shlxthdl\ooofilt_x64.dll
C:\Program Files (x86)\LOdev 4.0\program\shlxthdl\shlxthdl_x64.dll

to 

C:\Program Files (x86)\LibreOffice 3.6\program\shlxthdl
(save original files first!)

Manually registering the following dlls (admin rights needed):

regsvr32 "C:\Program Files (x86)\LibreOffice 3.6\program\shlxthdl\ooofilt_x64.dll" 
regsvr32 "C:\Program Files (x86)\LibreOffice 3.6\program\shlxthdl\shlxthdl_x64.dll"


ifilter settings AFTER file replacement:
ooofilt_x64.dll	OpenDocument Format Filter		4.0.0.12	4.0.0.12	The Document Foundation	C:\Program Files (x86)\LibreOffice 3.6\program\shlxthdl\ooofilt_x64.dll	{7BC0E713-5703-45BE-A29D-5D46D8B39262}	{7BC0E710-5703-45BE-A29D-5D46D8B39262}	23.12.2012 02:46:26	
==============================================
Recreating index - nothing changed.

That's what happened for me with Beta 1, so obviously nothing has changed in Beta 2.

I ended up reinstalling an earlier version of OpenOffice to get the filters, but I've started using LibreOffice for my actual document creation/editing, on the assumption (which may be misguided) that it will get more development than OpenOffice as time goes on.  I'd never heard of it until this isssue of filters arose (Apache accidentally missed out their 64 bit filters).   The green LibreOffice image doesn't inspire me, it looks far more clunky than the polished OpenOffice image.

Trying to find a short term solution I installed Microsoft Office 2010 filterpacks (64bit version):

http://www.microsoft.com/de-de/download/details.aspx?id=17062#overview

plus
Service Pack für Microsoft Office Filter Pack 2010 (KB2460041), 64-Bit Edition

IFilter view after installation:

odffilt.dll	Open Document Format ODT Filter	Microsoft Filter for Open Document Format	2010.1400.6019.1000	2010.1400.6019.1000	Microsoft Corporation	C:\Program Files\Common Files\Microsoft Shared\Filters\odffilt.dll	{34CEAC8D-CBC0-4f77-B7B1-8A60CB6DA0F7}	{9FBC2D8F-6F52-4CFA-A86F-096F3E9EB4B2}	25.12.2012 18:56:02
	
odffilt.dll	Open Document Format ODS Filter	Microsoft Filter for Open Document Format	2010.1400.6019.1000	2010.1400.6019.1000	Microsoft Corporation	C:\Program Files\Common Files\Microsoft Shared\Filters\odffilt.dll	{3DDEB7A4-8ABF-4D82-B9EE-E1F4552E95BE}	{E2F5480E-ED5A-4DDE-B8A8-F9F297479F62}	25.12.2012 18:56:02
	
odffilt.dll	Open Document Format ODP Filter	Microsoft Filter for Open Document Format	2010.1400.6019.1000	2010.1400.6019.1000	Microsoft Corporation	C:\Program Files\Common Files\Microsoft Shared\Filters\odffilt.dll	{E2F83EED-62DE-4A9F-9CD0-A1D40DCD13B6}	{4693FF15-B962-420A-9E5D-176F7D4B8321}	25.12.2012 18:56:02	

creating new index ...

seems to content index .ODT .ODS and .ODP files. Still waiting for the final solution - but at least for me, this is working.  (v3.6.4.3)

I would like to add, that LibreOffice 4.0RC1 does NOT fix the indexing bug.

LO 4.0RC2: Same result - LibreOffice 4.0RC2 does NOT fix the indexing bug.

LO 4.0RC3: Same result - LibreOffice 4.0RC3 does NOT fix the indexing bug.

Because this bug is confirmed already this much, I mark this bug as NEW.

András, it seems, this bug is related to the closed Bug 47805, isn't it?

László, in that case in addition to
Bug 47805
there is also
Bug 50623
Bug 47949
Bug 36950

Whatever it is, it was fine in OpenOffice before LibreOffice took over, though Apache folk subsequently broke it in a different way in OpenOffice, which the folk over there are now in the process of fixing!

I now use LibreOffice (3.6.4.3) but I also have OpenOffice installed (a version before OOO messed this up) and that solves the problem as the filters from OOO search the LibreOffice files.  

What I didn't know was (a) that LibreOffice existed at all (until OOO broke Windows 64 search and I started Googling)  (b) that it existed back in the beginning of 2011!

I would like to add, that it is possible to use the (working) filter DLLs from OpenOffice 3.3.0 to LibreOffice 4.0:

Solution for LibreOffice 4.0 on Windows 7 x64:

0. Install LibreOffice 4.0
1. Get a copy of OpenOffice 3.3.0 install file: OOo_3.3.0_Win_x86_install_wJRE_en.exe (or whatever language you need)
2. Extract this archive into a directory using 7zip
3. Open openofficeorg1.cab using 7zip and copy ooofilt_x64.dll and shlxthdl_x64.dll to a known place
4. Now you have to copy ooofilt_x64.dll and shlxthdl_x64.dll into 
   "C:\Program Files (x86)\LibreOffice 4.0\program\shlxthdl\"  (maybe saving both existing DLLs first - just in case)
5.  Register the following dlls manually (admin rights needed):

regsvr32 "C:\Program Files (x86)\LibreOffice 4.0\program\shlxthdl\ooofilt_x64.dll" 
regsvr32 "C:\Program Files (x86)\LibreOffice 4.0\program\shlxthdl\shlxthdl_x64.dll"

6. Optionally check result by using search_filter_view:

http://www.nirsoft.net/utils/search_filter_view.html

This should show File Version 3.03.9556 for ooofilt_x64.dll

7. Re-Index

Sorry - I forgot propertyhdl_x64.dll:

3. Open openofficeorg1.cab using 7zip and copy ooofilt_x64.dll, shlxthdl_x64.dll and propertyhdl_x64.dll to a known place
4. Now you have to copy ooofilt_x64.dll, shlxthdl_x64.dll and propertyhdl_x64.dll into 
   "C:\Program Files (x86)\LibreOffice 4.0\program\shlxthdl\"  (maybe saving existing DLLs first - just in case)

Everything else unchanged.

Problem description:
Same observations with LO 3.6.4, 3.6.5 and 4.0release often reproduced in the last weeks and months!
I tested several times on different machines and under Windows7-Ulimate-32bit, Windows7-prof-64bit and Windows XP SP3 with equivalent results. 
So I confirm all above bug reports.

Steps to reproduce:
1. Install current LO.
2. Create new Document, for example .odt with a specific term.
3. Search for that term with Windows Search. You will not find your new document. If there was a prvious installation of OO or LO 3.5. or older, you might see some older odt-documents in search results.
4. Rebuild index. You will not find any more .odt-Documents at all in search results.
5. Create new .odt-document(s) and observe indexing options. You can observe, that the number of indexed elments is increased, but you will not find any terms from within these documents.

Current behavior:
Obviously searchfilters are installed and registered correctly, but when indexing contents are not determined correctly.

Expected behavior:
Normal behavior of Windows Search includung content of Open-Document files...

Workaround:
Just save the dlls of 3.5.7's folder ..program\shlxthdl\ (or extract them from the installation file) and replace the correspondent dlls of 3.6 or 4.0 and rebuild serch index.

Research: 
Unfortunately I am not a skilled Windows-Programmer nor is it easy to get specific information about the functioning of Windows search. Just found http://msdn.microsoft.com/En-US/library/bb266532.aspx and http://www.nirsoft.net/utils/search_filter_view.html helpful. But after all I came to the conclusion that installation and registration of all filters are correct both for 32bit and 64bit-installations.
Looking in the sources and comparing 3.5.7 with actual versions there are only slight differences in the source codes of the filter-dlls, but there is a completely new structure of the makefiles. It might be worth to study this, but I have not enough background, sorry.
But no matter what: It is hard to understand, why this bug is not recognised by more people and not taken care of after months!

Duplicate:
There is an equivalent Bug report: "Bug 56035 – Windows search" in a different section: Component "Installation".

PeterR: thanks for the links, it seems, this problem has been confirmed by András Tímár, too (see https://bugs.freedesktop.org/show_bug.cgi?id=47949#c4). LibreOffice based on the Go-oo OpenOffice.org variant.

Karlheinz: I agree, Windows Search for OpenDocument files could have high importance especially in enterprise environment. Maybe the latency of the version update is higher here.

*** Bug 59315 has been marked as a duplicate of this bug. ***

@Fridrich: this may be a regression from the minizip removal. Read Comment 20 only, it is a concise summary.

Problems as described in Comment 20 remain unchanged in current LO 4.0.1.2 Testedition on 32bit Windows7.

I fixed this issue just hours after the 4.1.0 RC3 was tagged and it is included now in master, libreoffice-4-1 and libreoffice-4-0 branches. It will be in the next release of 4.0.x series and in 4.1.1.

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.

Same here: 
Platform: Windows 7 Professional 32bit, 
after install of LO 4.1.1RC2, Windows SearchFilterHost.exe eats 100% CPU time for about 12 hours while reindexing until killing the process. 
Replacing ooofilt.dll, propertyhdl.dll, shlxthdl.dll with versions from OpenOffice 3.5.7 solved the problem. Reindexing took 30 minutes.

If that's the case then it doesn't seem "Resolve - Fixed" to me!  Will be continuing with my old version of LibreOffice and my old OpenOffice DLLs for now.  I always like to update to latest versions but sometimes if the new one breaks things I stick with an old one.  If it ain't broke ...

This case seems to be resolved for me. The Filters might perhaps not work very efficiently, but there is no bug. I tested on Windows7, 64- and 32-bit machines. Searchfilterhost.exe caused high CPU-Load for some time (on my 32bit Core-Duo-machine with 400 000 Files in the Index for four days, including several pauses because of powermanagment, but then it's over...), but then the index is rebuilt and the files are indexed correctly.

(In reply to comment #29)
> This case seems to be resolved for me. The Filters might perhaps not work
> very efficiently, but there is no bug. I tested on Windows7, 64- and 32-bit
> machines. Searchfilterhost.exe caused high CPU-Load for some time (on my
> 32bit Core-Duo-machine with 400 000 Files in the Index for four days,
> including several pauses because of powermanagment, but then it's over...),
> but then the index is rebuilt and the files are indexed correctly.

I guess the question for the developers would be "is this sort of time for indexing to be expected?"  My particular case (running over 10 hours for <10,000 files was run on a netbook (Atom N280, 2 GB memory, SSD hard drive), and even then it didn't run to completion.  Should it be taking at least an order of magnitude longer than if the filters are uninstalled?  If these sort of runtimes are not expected, then it should be considered a bug to be investigated.  

Some comment from the developer would be very helpful.

I totally agree, John! Especially some comment of the developers would make it easier to test and to look for the problems in detail.
I was two fast in my last comment. Just after checking some emails, without creating new documents, SearchFilterHost starteted to work again and CPU-load is over 50% now for hours. This is not acceptable.
Are there any hints, what we can do to help?

Windows search crates a Log-File C:\Program Files\Common Files\microsoft shared\MSSearch_\Search\Data\Applications\Windows\MSS.log, but it is not readable, some binary code.
In my local "Ereignisanzeige" (Event Log?) there are hundreds of warnings within the last days like:
Protokollname: Application
Quelle:        Microsoft-Windows-Search
Datum:         05.09.2013 16:18:55
Ereignis-ID:   10023
Aufgabenkategorie:Gatherer
Ebene:         Warnung
Schlüsselwörter:Klassisch
Benutzer:      Nicht zutreffend
Computer:      EUMEL7
Beschreibung:
Der Protokollhostprozess 3852 hat nicht reagiert. Das Beenden des Prozesses wird erzwungen {Filterhostprozess 1148}. 

Ereignis-XML:
<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
  <System>
    <Provider Name="Microsoft-Windows-Search" Guid="{CA4E628D-8567-4896-AB6B-835B221F373F}" EventSourceName="Windows Search Service" />
    <EventID Qualifiers="32768">10023</EventID>
    <Version>0</Version>
    <Level>3</Level>
    <Task>3</Task>
    <Opcode>0</Opcode>
    <Keywords>0x80000000000000</Keywords>
    <TimeCreated SystemTime="2013-09-05T14:18:55.000000000Z" />
    <EventRecordID>144695</EventRecordID>
    <Correlation />
    <Execution ProcessID="0" ThreadID="0" />
    <Channel>Application</Channel>
    <Computer>EUMEL7</Computer>
    <Security />
  </System>
  <EventData>
    <Data Name="ExtraInfo">
    </Data>
    <Data Name="ProtocolHostProcessID">3852</Data>
    <Data Name="FilterHostProcessID">1148</Data>
  </EventData>
</Event>

Does this help?

Stopping and restarting the Indexservice seems to help a little bit against heavy CPU-loads.
But I started some diagnosis for Search-Protocol-Handlers in the Event-Logs and got some infomation, which shows evidence, that there could be something wrong with the installation. For example after creating and editing a copy of an OpenDocument-File "leo.odt":
Protokollname: Microsoft-Windows-Search-ProtocolHandlers/Diagnostic
Quelle:        Microsoft-Windows-Search-ProtocolHandlers
Datum:         05.09.2013 17:22:49
Ereignis-ID:   58
Aufgabenkategorie:(35)
Ebene:         Informationen
Schlüsselwörter:File Protocol Handler, USN notifications,Events reported per each item indexed
Benutzer:      SYSTEM
Computer:      EUMEL7
Beschreibung:
Die Beschreibung für die Ereignis-ID "58" aus der Quelle "Microsoft-Windows-Search-ProtocolHandlers" wurde nicht gefunden. Entweder ist die Komponente, die dieses Ereignis auslöst, nicht auf dem lokalen Computer installiert, oder die Installation ist beschädigt. Sie können die Komponente auf dem lokalen Computer installieren oder reparieren.

Falls das Ereignis auf einem anderen Computer aufgetreten ist, mussten die Anzeigeinformationen mit dem Ereignis gespeichert werden.

Die folgenden Informationen wurden mit dem Ereignis gespeichert: 

D:\Users\lorenzk\Desktop\Leo - Kopie.odt

Die Meldungs-ID für die gewünschte Meldung wurde nicht gefunden

Ereignis-XML:
<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
  <System>
    <Provider Name="Microsoft-Windows-Search-ProtocolHandlers" Guid="{dab065a9-620f-45ba-b5d6-d6bb8efedee9}" />
    <EventID>58</EventID>
    <Version>0</Version>
    <Level>4</Level>
    <Task>35</Task>
    <Opcode>0</Opcode>
    <Keywords>0x8000000002000008</Keywords>
    <TimeCreated SystemTime="2013-09-05T15:22:49.494948900Z" />
    <EventRecordID>1</EventRecordID>
    <Correlation />
    <Execution ProcessID="6096" ThreadID="5936" ProcessorID="0" KernelTime="1" UserTime="0" />
    <Channel>Microsoft-Windows-Search-ProtocolHandlers/Diagnostic</Channel>
    <Computer>EUMEL7</Computer>
    <Security UserID="S-1-5-18" />
  </System>
  <EventData>
    <Data Name="Description">D:\Users\lorenzk\Desktop\Leo - Kopie.odt</Data>
  </EventData>
</Event>

Nevertheless, we need more of developer's know how.

I should have been more careful with my last 3 postings. Maybe this was not only caused by ooofilt alone...
In the past I had used "Microsoft Office 2010 Filter Packs" to find odt-files (see comment 11) and they were not properely uninstalled (but the OO/LO-Extensions were not registered with the filterpack). So the eventlog messages might have had to do with an unclean system.
After finding out about this with "searchfilterview", I reinstalled and then uninstalled the MS-filterpack successfully. Result: After several days no more odt-Files were found, odt-Extensions were not registered any more for content-search. Repairing the LO-Installation helped, I forced reindexing. Now rebuildung the index takes place and it will probably take four days (machine may be awake for perhaps 8 hours/day, 400000 documents). Indexing speed seems not to be unusual with ooofilt.
Windows search is a mystery...

I have just done a clean install of Windows 7 64-bit SP1 and LibreOffice 4.1.1.2. The OpenDocument Format Filter was not searching inside odt files.

I tried numerous workarounds described here and elsewhere. Including installing the MS Office 2010 Filter pack. This did not work. As part of this process I was examining the registry entries for the OpenDocument Format Filter. When I finally gave up I uninstalled the MS Office filter pack, then ran the repair on LibreOffice to make sure it was installed correctly.

After doing this, the filter started behaving correctly, and examining the registry revealed a key which was not previously present.

The new key is:

[HKEY_CLASSES_ROOT\CLSID\{7BC0E710-5703-45BE-A29D-5D46D8B39262}\InprocServer32]
"ThreadingModel"="Apartment"
@="C:\\Program Files (x86)\\LibreOffice 4\\program\\shlxthdl\\ooofilt_x64.dll"

I believe the installation procedure is not correctly installing the filter, and performing the repair causes the missing key to be produced.

When I did the original installation of LibreOffice, I selected a custom installation, but left all the default options on (I just wanted to see what options were available).

reset version to oldest known-broken version

I would like to add my experiences with newest release (4.1.2.3) and have to confirm that the Windows Search problem still exists:

 - installation of version 4.1.2.3 > noisy computer, high CPU-usage from Windows searchindexer (up to about 30%), often unresponsive and not usable system, almost never ending indexing procedure, many Windows error event entrys (up to every 7 minutes) as described by Karlheinz in comment 32 ...
 - re-indexing didn't solve the problem
 - re-installation of Windows Search (with deleting the folder of the search database) didn't solve the problem
 - I can't detect the registry error as suggested by hdn@doctor-nemesis.org.uk in comment 35
 - I don't have any 'exotic' search filters or unclean deinstalled search filters as Karlheinz suggested in comment 34 (just Windows own, MS-Office 2007 and Acrobat 64-bit filters)
 - changing from 4.1.2.3 dll's to version 3.5.3.2 (the latest I could find in my backups before of version 3.6.2.2) > usable silent system, CPU-usage of Windows searchindexer up to 2%, almost no Windows error event entrys for Windows Search, indexing of my computer took about half a day

But this solution seems not to be exactly brilliant ('not the yellow of an egg' as you say in German):
 - for months I've registred that something 'occupies' my computer with a lot of workload, I've spend several hours in excluding programs and folders from anti-virus software, reducing priority of different processes, deactivating services and so on, it has been very very annoying
 - the dll's from the version I've chosen seems not to be capable to find words with special characters, i.e. German umlauts ä, ö, ü, while these words found in corresponding MS-Word documents and pdfs

Conclusion:
 - this problem is not solved since several versions, despite of comment 25
 - this problem is an important one and is worth to be documented in the list of 'most annoying bugs' so that the normal user can check for it in an easy way
 - this problem should be solved with high priority

Thanks

I think that fix for bug 56007 also fixes this one. Underperforming zip operations affect the indexer, too. Can you please check it in latest master? 
Don't forget the WRITE_REGISTRY=1 property:

msiexec /i master~2013-10-16_01.30.44_LibreOfficeDev_4.2.0.0.alpha0_Win_x86.msi WRITE_REGISTRY=1

(In reply to comment #38)
> I think that fix for bug 56007 also fixes this one. Underperforming zip
> operations affect the indexer, too. Can you please check it in latest
> master? 
> Don't forget the WRITE_REGISTRY=1 property:
> 
> msiexec /i
> master~2013-10-16_01.30.44_LibreOfficeDev_4.2.0.0.alpha0_Win_x86.msi
> WRITE_REGISTRY=1

Hallo Andras

Thanks for your immediately and really helpful reply. I've tested version 4.2.0.0 now in behalf of its behavior in Windows search. 

First: the indexing works like a charm! My computer stays responsive all the time and Windows didn't receive any error events in this time from search service. 

Second: to evaluate the search results was a little bit strange because of some words are found, others not. According to my previous post I'm now sure that this is not a problem with German umlauts. It's just that some documents are not indexed! But which documents are not indexed? All of the tested documents belongs to a serie of 11 older .odt-documents linked in one .odm (OpenDocument Master Document). One of them seems to be fully indexed, the other 10 not at all. I've found 1 difference between the indexed document and the not indexed documents: all of them are heavily referenced to each other. But the one document which is indexed only contains internal references, whereas the other - not indexed - documents all do contain internal and EXTERNAL references (links to other documents of this serie). So, when I do open one of them directly, these external references seem to be broken. But when I work with these documents inside the master document all these links are correct. I think that the indexing is stumbled across these external references. Is it possible? Should it be corrected?

Third: may I use the 4.2.0.0 indexing dll's with version 4.1.2.3 or do I have to expect serious side-effects?

Fourth: I don't understand the connection between the indexing problem and the problem with explorer shell extension. And what did you meen with mentioning 'Underperforming zip operations'?

Conclusion: who ever did this work is my hero of the day! He/she/they resolved a problem existing for over one year. This solution nearly works perfect for me and I'm hopeful that the minor problems will be also resolved in near future.

reply to comment #39)
First: thanks for confirming the fix, I set this bug to RESOLVED FIXED.

Second: Does it work with indexer from LibreOffice 3.5? Please file a new bug for this issue, because this issue is heavily overloaded.

Third: You can use dll from 4.2 in 4.1.x. 4.1.4 will contain the fix.

Fourth: OpenDocument files are zip archives. In LibreOffice 3.6 we replaced the zip implementation in shell extensions. It was identified, that the new implementation read the files 1 byte at a time, instead of reading larger blocks at a time. It caused high loads and latency.

(In reply to comment #40)
> reply to comment #39)
> First: thanks for confirming the fix, I set this bug to RESOLVED FIXED.
> 
> Second: Does it work with indexer from LibreOffice 3.5? Please file a new
> bug for this issue, because this issue is heavily overloaded.
> 
> Third: You can use dll from 4.2 in 4.1.x. 4.1.4 will contain the fix.
> 
> Fourth: OpenDocument files are zip archives. In LibreOffice 3.6 we replaced
> the zip implementation in shell extensions. It was identified, that the new
> implementation read the files 1 byte at a time, instead of reading larger
> blocks at a time. It caused high loads and latency.

Thanks again!

According to your question ('Second'): Yes, I think version 3.5 has this problem too because off as I mentioned in comment 37 some words were not found and the documents I've tested then have been the same I've tested for comment 39. I've just opend a new bug report: https://bugs.freedesktop.org/show_bug.cgi?id=70567

Greetings, Olaf

Sorry, didn't know that with a new comment the status will be reset to REOPENED, have set it back

Extracted ooofilt.dll, propertyhdl.dll and shlxthdl.dll from master...4.2.0.0*.msi and replaced the correspondent Files of my 4.0.5-Installation on Windows7-32bit. Windows indexing did not work in odt-files any more. Obviously a too simple approach.
Please tell me, when and how I can help testing on 4.0 and 4.1-installions.

(In reply to comment #43)
> Extracted ooofilt.dll, propertyhdl.dll and shlxthdl.dll from
> master...4.2.0.0*.msi and replaced the correspondent Files of my
> 4.0.5-Installation on Windows7-32bit. Windows indexing did not work in
> odt-files any more. Obviously a too simple approach.
> Please tell me, when and how I can help testing on 4.0 and 4.1-installions.

I've tested indexing on a Windows 64-bit system, perhaps this makes the difference?

Good news after testing on two Windows7-x64 machines with LO 4.1.2:
Indexing works fine and with good performance after exchanging the DLLs.

The problem was, that I tested with LO 4.0.5 first and there we do not have DLLs of Microsoft C Runtime Library in the shlxthdl-folder. Consequently i did not extract them from master*Dev_4.2.0.0.alpha*...
With LO 4.1 we clearly need msvcp110.dll and msvcr110 besides ooofilt.dll, propertyhdl.dll and shlxthdl.dll, in 64-bit-systems additionally ooofilt_64.dll, propertyhdl_64.dll and shlxthdl_64.dll. Using all these DLLs provides good indexing in LO 4.0 too.

*** Bug 68818 has been marked as a duplicate of this bug. ***

Updated machines to 4.1.3 und 4.0.6 on Windows XP and 7 (32 and 64Bit).
Both versions include the old, performance eating version of Windows search.
In LO 4.1.3 it is possible to replace correspondent DLL-files from master*Dev_4.2.0.0.alpha*... and indexing works fine. 
In LO 4.0.6 this does not function, even though it was possible in 4.05.

4.0.6 is considered as a final version. Is it really ok, to leave a final version with a long known and rather critical bug?

The Whiteboards shows 4.2 and 4.1.4 as target. Any specific reason you don’t like to use 4.1.x?

In almost all machines, I am responsable for, I use to use the latest stable version.
In my personal machine I need "Duden Rechtschreibung", which can be adapted to LO4.0 (not to 4.1) with workarounds.

But my question is more general:
- All versions of 3.6 did not index...
- Lo 4.0 did not index up to 4.0.3...
- Now indexing works, but there is a severe performance-problem.
- For one and a half year LO had these problems, publishing two final versions. There is not even a comment about the problem in the release notes.
- There is a solution for these problems.

Is it good for OpenSource to leave users alone with very annoying problem?

Please don't take my comments personally:

(In reply to comment #47)
> 4.0.6 is considered as a final version. Is it really ok, to leave a final
> version with a long known and rather critical bug?

Yes it is, we don't support 4.0.6 any longer, please see https://wiki.documentfoundation.org/ReleasePlan#4.0_release
We can't release 100th's of versions of 4.0-branch. People higher in the meritocratic ranking made this release schedule, which makes perfectly sense. Code develops continuously. And to look 2 major versions back as "will my patch work on that version too?" is a waste of time for every developer. It is even hard to backport a fix due the major code changes in some areas. And as every Open Source project, developer/volunteer time is gold. If you really want this patch inside a 4.0.x version, please look at this page to build your own LibreOffice. Then you can pull the fix and build your own version (hey! it's open source, remember?): https://wiki.documentfoundation.org/Development/BuildingOnWindows

(In reply to comment #49)
> In almost all machines, I am responsable for, I use to use the latest stable
> version.
> In my personal machine I need "Duden Rechtschreibung", which can be adapted
> to LO4.0 (not to 4.1) with workarounds.

See : https://bugs.freedesktop.org/show_bug.cgi?id=59107#c9
Not going to start a discussion, I'm going to lose that because I'm not a developer, but it looks to me that it's Duden's choice not to support LibreOffice anymore due not fix the link to libraries... I don't see why 1 extension should mean that LibreOffice has to change the whole release schedule?
 
> But my question is more general:
> - All versions of 3.6 did not index...
> - Lo 4.0 did not index up to 4.0.3...
> - Now indexing works, but there is a severe performance-problem.
> - For one and a half year LO had these problems, publishing two final
> versions. There is not even a comment about the problem in the release notes.

This has to be addressed (which is done correctly by creating a bug report) and has to be added manually (or marked as MAB, but I'm not sure it applies to the requirements to mark it as such).

> - There is a solution for these problems.
> 
> Is it good for OpenSource to leave users alone with very annoying problem?

Sorry, I don't agree what you're saying... As mentioned before: we have a release plan, we can't change the whole schedule because of an extension that doesn't support LibreOffice any longer. Otherwise you probably could upgrade to 4.1.4 really that'll be released really soon, which fix this bug.

PS: if you really would continue this discussion about our release schedule, please do at our mailing list: http://www.libreoffice.org/get-help/mailing-lists/

Kind regards,
Joren