You are not logged in.
Did anyone get strigi to actually SEARCH something? I'm using KDE 4 from official repos (not mod), now 4.2, and still I don't know how to use it. Strigiapplet is in unsupported repo and for KDE3, kio_slave never worked for me. I'm starting to think that strigi is just plain useless. Or maybe I'm just too stupid?
Can anyone tell me where can I find some comprehensive howto for searching with strigi?
Offline
Open krunner (Alt-F2), and type something. If strigi is enabled, results should be shown automatically.
Offline
Well your post made me try it
I've always thought that it would take gigabytes of space and slow my pc to a crawl but Instead it didnt scan home for too long.
Stats:
indexed files: 4,356
Nepomuk store size: 56,5MiB
Comprehensive howto:
1: open systemsettings -> advanced -> Desktop search
2: define searchable folders
3: start strigi
4: wait for it to finish
5: search (alt+f2 & word seems pretty easy way to use it)
Offline
Thansk for quick answers
Well, it looks like strigi doesn't want to work for me. Even though I turn it on in system settings, whenever I look there it says "strigi service is not running", trying to run strigidaemon from console, gives me this error:
WARNING: field 'http://strigi.sf.net/ontologies/0.9#debugParseError' is not defined in any rdfs ontology database.
terminate called after throwing an instance of 'CLuceneError'
Przerwane
and strigiclient shows blank fields. I've reinstalled clucene to no avail. Well, I think I'll just have to live without desktop searching the files.
Offline
I'm having the same problem. Is this the case of a bad package or a missing dependency?
I appreciate any help. I want to get the nepomuk/strigi combo working so I can finally use the nepomuksearch kio slave working properly to use it on my folder view plasmoid.
Offline
Thansk for quick answers
Well, it looks like strigi doesn't want to work for me. Even though I turn it on in system settings, whenever I look there it says "strigi service is not running", trying to run strigidaemon from console, gives me this error:
WARNING: field 'http://strigi.sf.net/ontologies/0.9#debugParseError' is not defined in any rdfs ontology database. terminate called after throwing an instance of 'CLuceneError' Przerwane
and strigiclient shows blank fields. I've reinstalled clucene to no avail. Well, I think I'll just have to live without desktop searching the files.
I think it is some sort of bug, possibly only hit when upgrading strigi. I had the same (?) issue and reported it here: https://bugs.kde.org/show_bug.cgi?id=181809
The problem is that I accidentally changed the ~/.strigi folder before I could create a meaningful backtrace. If anyone has this problem, is willing to recompile with debug symbols and then comment on the bug, I would appreciate it.
If you don't want to help out and just get it working, you could try deleting (or, if important stuff is indexed, moving) ~/.strigi
Offline
same problem here. although i do like the "select folders" "start strigi" workaround for the time being...eagerly awaiting a bugfix.
unless there is another way to force strigi to work with system settings?
Offline
Apparently Nepomuk has to be activated as well - if you haven't tried that.
Offline
Kde doesn't actually run strigidaemon, it has its own service for that purpose. It can be started manually with
nepomukservicestub nepomukstrigiservice
Checking "Enable Strigi Desktop File Indexer" in system settings starts (or tried to start) that service.
In my case it refused to run until I figured out that it needs a jre. I did have Sun's jre installed, but I had to manually link libjvm.so in /usr/lib for it to be found.
Offline
what about this error I always get:
Failed to contact Strigi indexer (No such method 'currentFolder' in interface 'org.kde.nepomuk.Strigi' at object path '/nepomukstrigiservice' (signature ''))
I found a bug here: http://bugs.kde.org/show_bug.cgi?id=176233
so it seems strigi not OK yet
Zygfryd Homonto
Offline
My 2 cents.
Strigi for me is actually useless. I got it working (linking libjvm.so in /usr/lib) but let's face the fact that much work has to be done. The main concern is that strigi does not index my mails.
If I'm wrong or if someone got it working (index emails I mean) I'd be glad to know. The problem is that normally you will make strigi start from the configurations settings (Advanced-->Nepomuk) and even if you make strigi index your home folder (Advance Settings under Nepomuk) the emails won't be indexed. On the contrary if you run strigidaemon from a terminal well...kmail emails (and all the subdirectories not excluded) will be indexed but a new directory will be created (.strigi in your HOME folder will al the configuration settings) and nepomuk will never look at it. I repeat...I'd be really glad if someone will clear this thing up.
Cheers
Offline
here is what i get when i run the services from terminal...i guess its all related huh?
[cucara@cucara ~]$ nepomukservicestub nepomukstrigiservice
nepomukstrigiservice(13113)/kdecore (KSycoca) KSycocaPrivate::openDatabase: Trying to open ksycoca from "/var/tmp/kdecache-cucara/ksycoca4"
nepomukstrigiservice(13113) Nepomuk::StrigiService::StrigiService: Will not start when using redland Soprano backend due to horrible performance.
then i end up with the "failed to contact..." message in they system settings window.
Offline
Strigi would not start until I fixed the broken sesame2 plugin for soprano.
IIRC strigi refuses to work when only redland is aviable, because redland is simply too slow to make sense.
The Archlinux soprano package is build against OpenJDK, and since I have Sun's JDK installed, sesame2 plugin did not load.
ldd reported missing link against libjvm.so. Symlinking did not help, but rebuilding soprano did the trick.
Best way for searches IMHO is the nepomuksearch:/ KIO slave. Just type nepomuksearch:/awesomeSearchTerm into dolphin's URL bar.
I'm not amazed by Strigi though; The results of searches seem rather random to me.
Offline
Strigi would not start until I fixed the broken sesame2 plugin for soprano.
IIRC strigi refuses to work when only redland is aviable, because redland is simply too slow to make sense.The Archlinux soprano package is build against OpenJDK, and since I have Sun's JDK installed, sesame2 plugin did not load.
ldd reported missing link against libjvm.so. Symlinking did not help, but rebuilding soprano did the trick.
Shouldn't this be reported as a bug (Dependency error)
(can't get strigi to work btw, checking if this is the cause)
Offline
It's worth using. Linking the libjvm.so as described above, plus updating .kde4/share/config/nepomukserverrc so that the sesame2 backend is used got it working.
There's an really helpful guide at http://kubuntuforums.net/forums/index.p … =3102231.0 for (many...) common problems.
Last edited by Wilfred (2009-05-19 23:03:18)
Offline
Thanks to the tips above (symlinking libjvm.so) I managed to get it working (kde 4.2.4). However, it takes a lot of resources, and seems to spend a huge amount of time to index only a few files. I started the indexation maybe 1 hour ago and only 3500 files were processed. (ATM it's indexing the openclipart directory at a very slow pace)
So, first part of the solution, locating libjvm.so (locate libjvm.so) and symlinking (sudo ln -s /opt/java/jre/lib/i386/server/libjvm.so /usr/lib/libjvm.so).
Well it turns out the redland backend is still used... Investigating
Edit : I got fed up and removed the whole ~/.kde4/share/apps/nepomuk and ~/.strigi directories and logged out/in. It worked This is the second part of the solution (as many files processed as before... within 1 minute
Last edited by mahen (2009-06-04 19:14:52)
Offline
Hmm, well... The sesame2 backend is definitely used (.kde4/share/apps/nepomuk/repository/main/data/sesame2 was created). However, it seems the indexation got slower and slower. 24000 files were indexed so far. It's been 50 minutes since I started it and in the first minute, 3000 files were indexed. So it seems to slow progressively down. (the indexer is still in my openclipart library...)
Any idea ?
(also, one CPU core is used to the max constantly)
Offline