After logging out of kde, I still find nepomukservice and virtuoso-t processes in and uninterruptable, broken state, meaning a reboot appears to be the only recovery. BSOD of some kind.

*** Bug 284063 has been marked as a duplicate of this bug. ***

*** Bug 272125 has been marked as a duplicate of this bug. ***

Problem persists using 4.8RC1 ppa packages on Kubuntu Oneiric. Makes the fan in my MacBook Air run like crazy thus creating a level of noise that makes the system unusable.

Yeah, it there still for me too. Ever since virtuoso hit KDE it has been terrible. Huge cpu-load and disk-io at times where *nothing* should be happenining g. It's almost like being on a wintendo-box.

KDE 4.8rc2 is much better I think. It might be psykological :)

Even though it is better than 4.8rc1 virtuoso-t still burn cpu-cycle af login. Could someone please explain why that is. It goes on for several minuttes.

Also regularly during the day virtuoso-t will "wake up" and spin for a few minuttes with no apparent reason.

I run kde 4.7.4, and its been a while sine I have had mush problems.
At login, nepomuk appears to scan for new files in any indexed folder, and sometimes I think it ONLY indexes new files at login, though. On the good side, it does not prevent me from using the system any longer, but that may have to do with better memory management somewhere in the chain.

It being better for me in rc2 might have something to do with having the file 
indexing turned off now.. But still virtuoso-t eats cpu at login, and several 
times during the day. It can't be looking for new files then ...

I know the database is used for mail also, but still - It eat a complete cpu-
core for several minuttes.

I must disagree. I see no improvements in 4.8 RC2.
- The same unchanged files and folders are constantly being reindexed
- The indexer chokes on small or zero byte files
- One CPU core is constantly at close to 100%
- The laptop as a consequence get hot with a lot of fan noise
- Only using email indexing does not help the CPU issue

The only thing that "helps" is to completely turn off desktop search and forcefully terminate the virtuoso-t process.

I agree. In general since kdepim changed backend to virtuoso-t things have 
slowed down a lot.

Do anyone know how to pinpoint what vituoso-t and the nepomuk-processes are 
doing. Some kind of log would help a lot I think - not all people see the 
exact same symptoms -  could be differences in files, memory, disk-type etc.

Is there a way to know which data/file causes the problem ?
strace doesn't seems to help when virtuoso-t is already at 100% CPU.

After upgrade to kde-4.8 (from 4.7) I also had 100% cpu from virtuoso-t all the time. The problem was, that by the upgrade to kde-4.8 many of my kde-settings where not restored, and the buggy krunner activated again. The problem of this cpu usage because of some krunner-plugin is known since over a year now, and still present in 4.8. For me the problem was solved now by deactivating all the krunner plugins in krunner-settings.

upgraded to 4.8.0 on fedora 16, on startup virtuoso-t seems to use the cpu sensibly, but then once its finnished its goes 100%

(In reply to comment #13)
> upgraded to 4.8.0 on fedora 16, on startup virtuoso-t seems to use the cpu
> sensibly, but then once its finnished its goes 100%
oh and disabling desktop search krunner does not help

I have the same issue and had it every time a major KDE update came in.
The only thing that helped me was disabling nepomuk, running a
rm -R ~/.kde4/share/apps/nepomuk
which basically removes all of nepomuks data and then restart nepomuk again.
Of course this leads to complete re-indexing of all files and all tags and ratings you might have given are lost.

I hope Sebastian is working on this issue because otherwise I resist to use the tagging and rating features as I'm just tired of loosing all the work I've done.

Yesterday I upgraded KDE from 4.7.4 to 4.8.0: Things were bad and got worse

In 4.7.4 nepomuk would reindex after every login for 1 hour files which where unchanged. Nempomuk is making a selection here, a complete indexing would run 24 hours. But that's another error.

Now in 4.8.0, after the unneeded reindexing, virtuoso-t remains in an endless loop, hogging 50% cpu time of each core.

(In reply to comment #15)
> I have the same issue and had it every time a major KDE update came in.
> The only thing that helped me was disabling nepomuk, running a
> rm -R ~/.kde4/share/apps/nepomuk
> which basically removes all of nepomuks data and then restart nepomuk again.
> Of course this leads to complete re-indexing of all files and all tags and
> ratings you might have given are lost.
> 
> I hope Sebastian is working on this issue because otherwise I resist to use the
> tagging and rating features as I'm just tired of loosing all the work I've
> done.

I have removed my ~/.kde4/share/apps/nepomuk folder, and indeed after a complete reindex, it is behaving as expexted

I've been having similar problems, and removing ~/.kde4/share/apps/nepomuk solved the problem -- at least for now.

@steffen, don't worry; he's hard at work... making this buggy software show the correct icons for TV shows and music: http://trueg.wordpress.com/

@Leon: I don't mind him playing arround with the technology as long as it keeps him motivated improving nepomuk. Let's face it: when the technology gets boring noone wants to maintain it and nepomuk is quite technical. 
Of course the migration issue is a big problem and probably very hard to fix or even to find the cause of the problems.
Maybe the maintainance, especially the migration part, of this technology could be improved with disposable virtual machines - For each version jump create a virtual machine loaded with nepomuk and some data. Then for testing the migration, just copy the image. If it fails, just try again.

Some comments:
- The apparent reindexing of files at startup is not an indexing. It is a check for changed and new files. Since Nepomuk is not guaranteed to be running all the time there is no other way to do this (short of the kernel patch which propagates up folder changes in mtime).
- The CPU hog in 4.8 is an Akonadi problem which is tracked in bug 289932.

Thus, I am closing this as a duplicate of the other one now as that seems to be the problem most of you are experiencing and the initial indexing will not be disabled by default (there is a hidden config option though: http://quickgit.kde.org/index.php?p=kde-runtime.git&a=commit&h=1dec4d056a3ef153de861ce32a2f5df20f1a0d4a)

*** This bug has been marked as a duplicate of bug 289932 ***