Hey John<div><br></div><div>Sorry, about the late reply. We Nepomuk developers have been kinda out of it lately. :)<br><br><div class="gmail_quote">On Fri, Apr 15, 2011 at 11:15 AM, john terragon <span dir="ltr">&lt;<a href="mailto:terragonjohn@yahoo.com" target="_blank">terragonjohn@yahoo.com</a>&gt;</span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi.<br>
I&#39;ve activated kde desktop search and nepomuk for the first time with the 4.6.1 release but I&#39;m having some problems with the correctness of the searc results. As a quick try, I set the indexable folders to a couple of them containing about 3500 files and 300 subdirs. After the initial indexing this is what I get:<br>


<br>
1) If I create, from console, a new file &quot;strange_name.txt&quot; containing a single word strange_word_1, then apparently it is immediately indexed by nepomuk and searching either for name or content with dolphin I get the correct file.<br>


<br>
2) If I modify &quot;strange_name.txt&quot; _from_console_ changing strange_word_1 with strange_word_2, then searching for &quot;strange_word_2&quot; with dolphin I don&#39;t get any result and I still get &quot;strange_name.txt&quot; if I look for &quot;strange_word_1&quot;. Not only it does not appear to update the index immediately but even after hours still no results for strange_word_2.<br>


<br>
3) If I modify &quot;strange_name.txt&quot; as in 2) but with a kde apps (kwrite) then I get &quot;strange_name.txt&quot; as a result of searching for content with &quot;strange_word_2&quot; BUT I still get &quot;strange_name.txt&quot; if i search for &quot;strange_word_1&quot; (which is not there anymore). And this is generalized: if I do n changes with &quot;strange_word_1&quot;,....&quot;strange_word_n&quot; I will still get<br>


&quot;strange_name.txt&quot; no matter which one of the strange_word I use to search.<br></blockquote><div><br></div><div>Confirmed! This is weird. </div><div><br></div><div>It seems to be some kind of inotify problem. The File watching service doesn&#39;t seem to be always sending the required signals. :/ The semi good news is that I think I&#39;ll be able to write a test case for the exact steps you&#39;ve described. I&#39;ll let you know what happens.</div>
<meta http-equiv="content-type" content="text/html; charset=utf-8"><div> </div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Even though I&#39;m just indexing 3500 files I increased the max_user_watches to 524288, as described in<br>
I read that blog post <a href="http://www.afiestas.org/nepomuk-is-not-fast-is-instant/" target="_blank">http://www.afiestas.org/nepomuk-is-not-fast-is-instant/</a>  (hoping that such an high number would induce nepomuk to put an inotify watch for each file indexed) but the results are still the same.<br>


<br>
Is this supposed to happen? Is it a known bug? Because performances with virtuoso are not bad (besides some crashes during the scanning) but the correctness of the searches after changes in the files is a big problem, for me at least.<br>
</blockquote><div><br></div><div>The crashes were probably caused by faulty Strigi plugins. We&#39;ll have to introduce some kind of multi-process architecture, so that the indexing does not stop if one of the strigi plugins crashes.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<br>
I&#39;m using debian unstable with the 4.6.1 (semi)-official kde packages from<br>
<a href="http://qt-kde.debian.net/" target="_blank">http://qt-kde.debian.net/</a>.<br>
<br>
Best<br>
john<br>
<br>
<br>
<br>
<br>
<br>
_______________________________________________<br>
Nepomuk mailing list<br>
<a href="mailto:Nepomuk@kde.org" target="_blank">Nepomuk@kde.org</a><br>
<a href="https://mail.kde.org/mailman/listinfo/nepomuk" target="_blank">https://mail.kde.org/mailman/listinfo/nepomuk</a><br>
</blockquote></div><br><br clear="all"><br>-- <br><font color="#999999">Vishesh Handa</font><br>
</div>