Version: (using KDE 4.4.0) OS: Linux Installed from: Archlinux Packages is it meant to? if so, i find it not usable. if not, it does not work correctly.
I experience the same problem. Huge waste of resources. Fedora 12 x86_64 KDE 4.4.0
I can confirm this bug and that is very annoying. Moreover, the results you get from a search depend on how many files have been re-indexed at the moment, really wasting all the previous indexing processes _completed_ before.
Does the count of files actually increase with each re-index?
The counter now is 320. Then, upon strigi re-activation (it was disabled automatically), slightly falls to 0. After, it comes up again to around 300 (304 to be precise), surprisingly is going down again(90). It seems to be on a roller coaster. :) Finally it stops at 321. What is funny is that there are at least 520 pdf inside one main folder.
Again, the counter has reached 322 (321+1) and then a new cycle has begun. Don't know what is wrong.
can you test a patch?
I am experiencing the same behaviour as above. Although after 4 days of indexing over and over (and the index counting backwards at times) it seems to have stabilized. The indexer is mostly inactive and after reboot it goes through the indexed /home to search for new files. So far so good. Although, as for the poster above, not all files are indexed (e.g. mails) even though strigi goes through ~/.kde/share/apps/mail/foo. Patch would be welcome. greetz devil
I guess that at least in my case there is a file (maybe a pdf) that forbids the indexing process, obliging strigi to restart because it has not completed its job, of course. This could be the reason of the loop. At the moment I have tried to exclude a whole directory on a different partition from the indexing process and strigi has been able to index my home directory. If I'm able to find the problematic file by trial-and-error I will post it.
Created attachment 41473 [details] Patch adds debug output to the strigi service Please apply this bug to kdebase and then recompile kdebase/runtime/nepomuk/services/strigi. Then please run the service manually from command line to see which files are removed and which are analyzed. This should give us more information on the issues.
Created attachment 41500 [details] Fixes the query filter creation to clean out unwanted entries when using multiple top-level folders Please apply in kdebase and see if it improves the situation.
Hello, I have the same problem. If I add a new file into an indexed folder then strigi will reindex all files in the folder and sub-folders. No other folders are reindexed. Also, during the reindexation process there is no way to search old indexed files (in that folder and its sub-folders). Finally, it does not index . (dot) files. I selected my Kmail folder for indexing but strigi returns nothing. The emails and other .kde files are indexed correctly with recoll. Regards. snvv
The same issue is here. Strigi starts re-indexing everything all over after I reboot the computer. Confirmed for KDE 4.7.2, 4.7.3, 4.7.4.
also for me the same strigi is always re-indexing everything at startup with large waste of resources
I am not having this problem since quite som time.
With 4.10, the file indexing infrastructure has been refactor substantially. This has been fixed. If you still encounter something like this please reopen this bug / file a new one.
A big thanks for all the work on nepomuk!