Hi,

when I read that the Nepomuk semantic desktop had "made leaps" with the new KDE 4.4 release I had sincerely hoped that it might actually had become usable. So I eagerly tried it out with the new release, but so far I haven't been able to make it work at all:

Strigi is taking ages to index my files. It's probably running on low-priority in order to not interfere with my "work", but I would really like it to hurry up since I have an annoying "virtuoso-t" process hanging around with constant 20% cpu load during the process.

When I try to search something using dolphin's search bar it takes AGES whilst the "virtuoso-t" rises up to 50% cpu load until any results are displayed. Most of the time it doesn't find anything even though the file I searched for is located directly in my home folder (probably because the index is still not complete? then what is strigi doing all the time?).

Now what really made me want to hit my head onto the table was the fact that 3 times out of 5 dolphin crashed after I modified the tags of a file using the sidebar.

What's even more ridiculous, is that I clicked on the tag in the sidebar after tagging the files and it tells me "No items found.". So it can't even find the files I just tagged.

When I look at my process table right now I can see a "nepomukservicestub" process (/usr/bin/nepomukservicestub nepomukfilewatch) process occupying 250mb of RAM, constantly growing. "dbus-daemon" occupying 100mb of RAM, constantly growing (WTF?) and a "virtuoso-t" process occupying 70mb of RAM whilst constantly taking 40-60% of cpu power.


Honestly, what were those "leaps" they were talking about. It still seems completely unusable and buggy to me. Guess I have no choice but to turn it off again, like I did until now.

I'd really like all those "cool features" that sound great in theory and look good on screenshots. In fact, all it does is wasting my system's resources like crazy (cpu time, ram AND disk space) while not providing ANY working functionality.

EDIT: "nepomukservicestub" now at 350MB ram - nepomuk store size (as reported by the tray application) at 730MB... Guess I better reboot before it crashes my system.

EDIT2: I disabled strigi and rebooted but I still had "virtuoso-t" taking up 50% cpu all the time. I had to disable Nepomuk completely to get rid of it.

Besides, with all the rant I forgot to provide some useful technical information:

I'm running 64bit Arch Linux with Arch's "official" KDE-4.4.0 packages. uname -a says

Code: Select all

Linux kellerkind 2.6.32-ck #1 SMP PREEMPT Sun Jan 3 23:05:02 CET 2010 x86_64 AMD Athlon(tm) 7750 Dual-Core Processor AuthenticAMD GNU/Linux

Nepomuk works bad with large databases and large hard drives so it's a good idea don't index all home directory tree.

If you use Akonadi then your nepomuk database is increased, in my case 150 MBytes , so system performance could be degraded.

Actually I don't upgrade to KDE 4.4 so I don't know if performance problems are solved with Virtuoso 6.1.0.

I removed my Nepomuk store, set strigi to ignore the "src" folder in my home directory (as it contains many many small text files) and waited patiently for strigi to finish. After it finished I again had a "nepomukservicestub" process taking about 400MB of memory, but it vanished, after I re-logged in.

Right now, it seems to have settled a bit. "virtuoso-t" takes about 50MB of memory but doesn't consume any CPU power anymore, unless you search for something.

However, searching itself is rather slow. When there are a lot of matches it can take more than 30 seconds for them to show up. At least it seems to correctly find files I tagged now.

I'm glad it works now (somewhat at least) but I still have a few questions:

- Can I tell strigi to index as fast as possible instead of idling around in the background? There is an option to suspend the indexer but I can't find an option to make it run at highest priority. Would be handy to have it build the index quickly when I'm not using the computer.

- When dolphin displays the results of a nepomuksearch is there some way I can find out where a file is located? I can preview and open it and all that, but it won't show me where the file is located until I open it with some external application which (hopefully) displays the full path in some way.

- when typing a search term dolphin's search bar gives useful recommendations. For example typing "c" pops up "content size". Typing the first letters of a tag shows "hasTag:...". But is it somehow possible to see an overview of what I can search for? Like a list of all tags and properties that were indexed?

- are there other (working) front-ends for Nepomuk (a plasmoid, perhaps)?

I think that is better other aproach with strigi. If you have problems with cpu usage the best solution is deactivate strigi and then, at night, activate it so strigi index all your hard disk when you are not using your computer.

Dolphin integration must be improved because sometimes result are really not accurate: files that don't exists, nepomuk tags pointing to nowhere, etc... I don't know any solution for your question neither if this feature will be added. You can add a entry in bugs.kde.org as a wish.

About front end you have PIMO but, is more a repository to manage nepomuk data than other thing. There is a plasmoid but I don't use it because is not really useful.

I also just noticed that results aren't actually sorted by file name, even though I clicked on the column. They don't seem to be sorted in any particular order.

Anybody here who's bored and wouldn't mind writing some kick-ass GUI for the desktop search?

I've updated to KDE 4.4 and gave nepomuk/strigi a try.
The indexing didn't take more than a few minutes.
I don't experience high CPU or RAM usage (as far as I know hehe).
But, searching in Dolphin gives no result (search term: "config". I have a file named config in my home folder, so...).
There's an interesting thing though. By clicking on "Query Results" you can unveil this text:

Code: Select all

nepomuksearch:/?sparql=select distinct ?r  where { { { ?r ?v1 ?v2 . ?v2 bif:contains "'config*'" . } UNION { ?r ?v1 ?v3 . ?v3 ?v4 ?v2 . ?v4 <http://www.w3.org/2000/01/rdf-schema#subPropertyOf> <http://www.w3.org/2000/01/rdf-schema#label> . ?v2 bif:contains "'config*'" . } . { ?r a ?v5 . ?v5 <http://www.w3.org/2000/01/rdf-schema#subClassOf> <http://www.semanticdesktop.org/ontologies/2007/03/22/nfo#FileDataObject> . } UNION { ?r a ?v6 . ?v6 <http://www.w3.org/2000/01/rdf-schema#subClassOf> <http://www.semanticdesktop.org/ontologies/2007/03/22/nfo#Folder> . } . } .  ?r <http://www.semanticdesktop.org/ontologies/2007/01/19/nie#url> ?v7 .  FILTER(REGEX(STR(?v7), "^file:///home/leo/")) .  }

If I delete all occurrences of websites and leave it as something like this:

Code: Select all

nepomuksearch:/?sparql=select distinct ?r  where { ?r ?v1 ?v2 . ?v2 bif:contains "'config*'" }

then I do get some results.

Could those links be some trash left out from testing time?

That possibly hints to a desynchronisation between Strigi / Soprano / Nepomuk as to what type certai things should be stored as.

Please file a bug report.

But, searching in Dolphin gives no result (search term: "config". I have a file named config in my home folder, so...).

I have exactly the same problem. The search is not very reliable.

For example I created a file named "acdef" in my home folder. When I search for "abc" it doesn't show any results but when I search for "abcdef" the file is found.

The same goes for file contents. Sometimes it quickly finds perfectly what I was looking for and sometimes it doesn't find anything at all even though I know the file is there.


And there's more: Strigi has "accidentally" indexed a source folder which contained many text files. I think that this slows the search process down greatly. Sometimes I have to wait 30 seconds or more until any results are displayed. I already unchecked the folder in the "Strigi Index Folders" tab but apparently it won't "forget" about it's contents.

Can I undo the indexing of a particular folder hierarchy without deleting and rebuilding my whole store?

The lack of unindexing I would consider to be a grave bug, please report it at bugs.kde.org.

The failure for it to find abcdef with the term abc is also a bug, please report that also.

Done:

https://bugs.kde.org/show_bug.cgi?id=226845

and

https://bugs.kde.org/show_bug.cgi?id=226849