Hi,
This is a fully updated F16 system running KDE.
"Nepomuk File Indexing Service Not Running" is the status that appears when I hover over the Neomuk icon in the SysTray. Additionally, if I bring up the "System Setting" application and choose "Desktop Search" the "System Settings" application will hang.
Obviously something got borked. How can I either track down what is borked or what can I safely delete to reinitialize the Nepomuk system?
Thanks, Ed
On 12/25/2011 08:30 PM, Ed Greshko wrote:
Hi,
This is a fully updated F16 system running KDE.
"Nepomuk File Indexing Service Not Running" is the status that appears when I hover over the Neomuk icon in the SysTray. Additionally, if I bring up the "System Setting" application and choose "Desktop Search" the "System Settings" application will hang.
Obviously something got borked. How can I either track down what is borked or what can I safely delete to reinitialize the Nepomuk system?
Turned out to be a problem with the strigi service. I think I was thrown off by the "hanging" System Services. It would hang and then come up with a dialog that asked if you wanted to terminate...which I did. But, it seems that if you let it go longer you would get the display.
Ended up copying the nepomukstrigirc file from a "working" user and a few other things and it is now working.
Of course, the question now is....do I really need/want to use these services......
On Monday 26 December 2011 18:27:28 Ed Greshko wrote:
On 12/25/2011 08:30 PM, Ed Greshko wrote: Of course, the question now is....do I really need/want to use these services......
Nepomuk and Strigi are one of the first things I shut down when I install a fresh Fedora with KDE. On every login they would start indexing the "desktop" or whatever (I have nothing bar two default icons in my Desktop folder), and then the virtuoso binary would start eating my CPU time for half-a-minute, before finally settling down. And I see absolutely no (obvious) use of all that on my machine.
So I shut them down, and never missed them since. :-) Though I am curious to know what would be their practical purpose (some reasonable usecase)...
HTH, :-) Marko
On 12/26/2011 06:41 PM, Marko Vojinovic wrote:
So I shut them down, and never missed them since. :-) Though I am curious to know what would be their practical purpose (some reasonable usecase)...
I'm leaning in that direction as well as I can't think of any benefit for me either.
I guess if you have lots of documents and need to find the one that is related to "march 23rd accident report" or something then it could be useful.
On 12/26/2011 10:41 AM, Marko Vojinovic wrote:
On Monday 26 December 2011 18:27:28 Ed Greshko wrote:
On 12/25/2011 08:30 PM, Ed Greshko wrote: Of course, the question now is....do I really need/want to use these services......
Nepomuk and Strigi are one of the first things I shut down when I install a fresh Fedora with KDE. On every login they would start indexing the "desktop" or whatever (I have nothing bar two default icons in my Desktop folder), and then the virtuoso binary would start eating my CPU time for half-a-minute, before finally settling down. And I see absolutely no (obvious) use of all that on my machine.
So I shut them down, and never missed them since. :-) Though I am curious to know what would be their practical purpose (some reasonable usecase)...
Nepomuk *should* not be a problem - strigi is the indexer, and is where the resource hog could be expected. AIUI, Strigi indexes the directories that you give access to, and Nepomuk allows all Ankonadi-aware applications to draw on the information in the databases. Of course this is not a complete description, but until someone comes up with a better one....
Anne
On Monday 26 December 2011 17:39:12 Anne Wilson wrote:
On 12/26/2011 10:41 AM, Marko Vojinovic wrote:
Nepomuk and Strigi are one of the first things I shut down when I install a fresh Fedora with KDE. On every login they would start indexing the "desktop" or whatever (I have nothing bar two default icons in my Desktop folder), and then the virtuoso binary would start eating my CPU time for half-a-minute, before finally settling down. And I see absolutely no (obvious) use of all that on my machine.
Nepomuk *should* not be a problem - strigi is the indexer, and is where the resource hog could be expected. AIUI, Strigi indexes the directories that you give access to, and Nepomuk allows all Ankonadi-aware applications to draw on the information in the databases. Of course this is not a complete description, but until someone comes up with a better one....
Right, but it still doesn't make much sense to me. If strigi is shut down, there is nothing in the database, so what would be the purpose of nepomuk to keep running in that case?
Also, is strigi indexing the contents of files, or just filenames? Can nepomuk be configured to use the mlocate database instead (or in addition to strigi)? If strigi indexes the file contents, what types of files can it read through? Can it index anything other than ASCII files, like libreoffice, pdf, djvu, tags in mp3, metadata in various audio/video files? Can it be used in conjunction with some OCR software to index scanned handwriting in jpeg files? Is it multilingual, ie. does it index stuff written in Cyrillic/Chinese/Hebrew/etc?
Next, which apps are "akonadi-aware"? How could they use the data indexed by strigi, and to what purpose?
I'd really like to see a real-world example of all this being useful. Otherwise it appears like a solution looking for a problem.
I can use locate to search through file names, and grep to search through file contents (even through binary files :-) ). So I expect that strigi/nepomuk/akonadi-aware app should be able to do more than that, right?
P.S. I am not trying to beat down nepomuk&strigi or something, rather I am genuinely curious about the whole concept... :-) A link to some website with the explanation of the idea behind all this would be very welcome...
Best, :-) Marko
On Mon, Dec 26, 2011 at 11:06 AM, Marko Vojinovic vvmarko@gmail.com wrote:
On Monday 26 December 2011 17:39:12 Anne Wilson wrote:
On 12/26/2011 10:41 AM, Marko Vojinovic wrote:
Nepomuk and Strigi are one of the first things I shut down when I install a fresh Fedora with KDE. On every login they would start indexing the "desktop" or whatever (I have nothing bar two default icons in my Desktop folder), and then the virtuoso binary would start eating my CPU time for half-a-minute, before finally settling down. And I see absolutely no (obvious) use of all that on my machine.
Nepomuk *should* not be a problem - strigi is the indexer, and is where the resource hog could be expected. AIUI, Strigi indexes the directories that you give access to, and Nepomuk allows all Ankonadi-aware applications to draw on the information in the databases. Of course this is not a complete description, but until someone comes up with a better one....
Right, but it still doesn't make much sense to me. If strigi is shut down, there is nothing in the database, so what would be the purpose of nepomuk to keep running in that case?
Nepomuk does more than file search. You could have info about tagged photos, artists in music libraries, etc. stored in it.
Also, is strigi indexing the contents of files, or just filenames?
Yes.
Can nepomuk be configured to use the mlocate database instead (or in addition to strigi)?
Not that I'm aware of. IIUC mlocate deals solely with filenames, while strigi operates on all sorts of data, so I'm not sure there's much benefit to doing so.
If strigi indexes the file contents, what types of files can it read through? Can it index anything other than ASCII files, like libreoffice, pdf, djvu, tags in mp3, metadata in various audio/video files?
Yes.
Can it be used in conjunction with some OCR software to index scanned handwriting in jpeg files?
I'm not aware of any OCR software that handles handwriting very well, nor would I want it to start randomly OCRing every JPEG I own. I don't think there's anything stopping someone from writing an app that OCRs documents and populating Nepomuk with the text, if someone finds that useful.
Is it multilingual, ie. does it index stuff written in Cyrillic/Chinese/Hebrew/etc?
Of course! KDE is generally very good about that kind of thing.
Next, which apps are "akonadi-aware"? How could they use the data indexed by strigi, and to what purpose?
All of the KDEPIM apps: KMail, Kontact, etc. For searching and fast filtering, I presume
I'd really like to see a real-world example of all this being useful. Otherwise it appears like a solution looking for a problem.
Part of the problem is that it has some dumb defaults. For instance, it only searches the Documents, Music, Movies, etc. folders that I rarely use. I always configure it to search my entire home directory. Another thing that annoys me is that KRunner doesn't do desktop search by default. Once that's enabled, KRunner becomes *a lot* more useful (e.g. more than just slightly faster than launching something on a terminal ;-).
Instead of manually browsing to a directory and opening a particular file, I just press ALT+F2, enter the first few characters, and hit Enter. I can search for artists in my music, pictures of my boyfriend, functions in source code, and start programs all in one text box.
I can use locate to search through file names, and grep to search through file contents (even through binary files :-) ). So I expect that strigi/nepomuk/akonadi-aware app should be able to do more than that, right?
For the same reason Google searches an index they build rather than "grepping" the Internet on the fly (or even their cached copy, presumably). It's more performant when you're searching a large amount of data. I don't know about yours, but "grep 'something' ~" would take hours on my machine. ;-)
If I'm looking for a particular function in a codebase, I'll probably still use grep. But, if I'm looking for some random letter I wrote six months ago and not sure where I stuck, I'd use KDE's desktop search.
-T.C.
T.C. Hollingsworth wrote:
Part of the problem is that it has some dumb defaults. For instance, it only searches the Documents, Music, Movies, etc. folders that I rarely use. I always configure it to search my entire home directory.
In fairness to upstream, these "dumb defaults" are fedora-only, it was a compromise between nepomuk's high cpu usage and keeping it in use for folders used by default for most users' indexible content.
-- rex
On Mon, Dec 26, 2011 at 5:26 PM, Rex Dieter rdieter@math.unl.edu wrote:
T.C. Hollingsworth wrote:
Part of the problem is that it has some dumb defaults. For instance, it only searches the Documents, Music, Movies, etc. folders that I rarely use. I always configure it to search my entire home directory.
In fairness to upstream, these "dumb defaults" are fedora-only, it was a compromise between nepomuk's high cpu usage and keeping it in use for folders used by default for most users' indexible content.
Actually, it's really just KRunner's default that bugs me, because in my experience turning on it's Nepomuk search doesn't slow it down much at all, but it makes KRunner 1000x more awesome. (Which is saying *a lot*, because even boring default KRunner is really awesome. ;-)
The folder thing I could care less about; there's no sensible default that would make me and my wacko partition layout happy and certainly none that would make *everyone* happy. I mentioned that mainly because it's something that would easily affect the usefulness of it for others.
TBH, I'm surprised you guys haven't turned the whole thing off yet, given all the crap you hear about it.
-T.C.
T.C. Hollingsworth wrote:
Actually, it's really just KRunner's default that bugs me, because in my experience turning on it's Nepomuk search doesn't slow it down much at all, but it makes KRunner 1000x more awesome. (Which is saying *a lot*, because even boring default KRunner is really awesome. ;-)
Once upon a time the nepomuk krunner plugin was very crashy. I suppose the situation should be re-evaluated these days.
-- rex
On Monday 26 Dec 2011 18:26:01 Rex Dieter wrote:
T.C. Hollingsworth wrote:
Part of the problem is that it has some dumb defaults. For instance, it only searches the Documents, Music, Movies, etc. folders that I rarely use. I always configure it to search my entire home directory.
In fairness to upstream, these "dumb defaults" are fedora-only, it was a compromise between nepomuk's high cpu usage and keeping it in use for folders used by default for most users' indexible content.
I still suffer with nepomuk/virtuoso's high cpu usage, checking the various dev's blogs and kde.bugs it is recommend testing with the newer (dev) releases of Akonadi, virtuoso etc
Normally stopping nepomuk, kmail2 and restarting them fixes the problem though..
Colin
On Monday 26 December 2011 12:23:17 T.C. Hollingsworth wrote:
On Mon, Dec 26, 2011 at 11:06 AM, Marko Vojinovic vvmarko@gmail.com wrote:
Can it be used in conjunction with some OCR software to index scanned handwriting in jpeg files?
I'm not aware of any OCR software that handles handwriting very well, nor would I want it to start randomly OCRing every JPEG I own. I don't think there's anything stopping someone from writing an app that OCRs documents and populating Nepomuk with the text, if someone finds that useful.
Just as a side remark... I wouldn't OCR *every* jpeg I own, but I *do* have a bunch of them under one particular directory structure, that are basically my own scanned handwritings (cca 3000 pages). The files are named file001.jpeg, file002.jpeg, etc., so it's essentially a hard guesswork to find the one I need to read (and their thumbnails all look the same :-( )... Also, I've seen some rather nifty OCR capabilities in recent touchscreen-tablet-computers, where you could handwrite on the screen and they would automatically OCR and convert it into TeX, complete with mathematical equations that you wrote down (I could only wish for something like that in Fedora!)...
My jpeg's are swarming with precisely such math stuff, so I guess it could be useful to have all that OCR'd and indexed automatically... ;-)
I'd really like to see a real-world example of all this being useful. Otherwise it appears like a solution looking for a problem.
Part of the problem is that it has some dumb defaults. For instance, it only searches the Documents, Music, Movies, etc. folders that I rarely use. I always configure it to search my entire home directory. Another thing that annoys me is that KRunner doesn't do desktop search by default. Once that's enabled, KRunner becomes *a lot* more useful (e.g. more than just slightly faster than launching something on a terminal ;-).
Instead of manually browsing to a directory and opening a particular file, I just press ALT+F2, enter the first few characters, and hit Enter. I can search for artists in my music, pictures of my boyfriend, functions in source code, and start programs all in one text box.
Ok, this sounds reasonable --- to have a system-wide content search facility, similar to what Google does Internet-wide. Although I doubt I would use such features myself --- I have a rather well-disciplined directory structure under ~, so I typically know where to look for what. And I am a bit weary of the overhead of maintaining the index database for a large quantity of files, on a moderate desktop/laptop machine.
But I guess it does make sense for some (most?) people. I've witnessed in recent times that people find it easier to fire up Google and search for the, say, Fedora Project home page, than to keep a bookmark for it. Even when they need to access the site repeatedly. ;-) So if someone is more used to "search- for-stuff" paradigm than to "keep-stuff-in-well-organized-places" paradigm, strigi&nepomuk might be a blessing... ;-)
Speaking of search-paradigms, I've also seen one person opening Google to find the home page of YouTube, than doing a search in YouTube for whatever he wanted... Looked kind of silly to me, but I guess Google has had a major influence lately on the ordinary people's workflow... ;-)
Anyway, thanks for the explanations!
Best, :-) Marko
Marko Vojinovic wrote:
Also, I've seen some rather nifty OCR capabilities in recent touchscreen- tablet-computers, where you could handwrite on the screen
When you write on the screen, the computer gets motion information, not just a static image, which makes it much easier to recognize characters.
Kevin Kofler
-
Anne Wilson -
Colin J Thomson -
Ed Greshko -
Kevin Kofler -
Marko Vojinovic -
Rex Dieter -
T.C. Hollingsworth