|
On Sunday, 27 October, 2013 13:02:11 Johannes Zarl wrote: > Hi, > > As I've written before[1,2], kmail2 has been very slow for me. Today, I > finally took the time to look into it and I found a workaround. In case > anyone else has got the same problem, maybe this will help: > > Since I had already turned off email-indexing, I somehow thought that > nepomuk cannot really to blame. Well, today I realized that my nepomuk > database uses 2.8 GB of storage! I have no idea how there could be as much > metadata for my files (~280.000) and email (maybe 10.000 mails total). > > Creating a new nepomuk database (therefore losing any ratings and other > metadata I might have entered previously) indeed solved the problem for me: > > 1. Disable nepomuk completely in control center ("kcmshell4 kcm_nepomuk") > 2. Kill remaining virtuoso-t processes > 3. cd ~/.kde/share/apps/nepomuk/ ; mv repository repository.bak > 4. Reenable nepomuk > > KMail is now as fast as it used to be. I've also reenabled file and email > indexing (mostly to see if the problems return). > > So before you give up on kmail completely, you might want to see if nepomuk > is the problem... > > Cheers, > Johannes > > > P.S.: I just realised that there is a program called nepomukcleaner which > supposedly cleans up corrupted databases. You might want to try this before > removing the database completely. > > > [1] https://lists.debian.org/debian-kde/2013/08/msg00009.html > [2] https://lists.debian.org/debian-kde/2013/10/msg00012.html
I have no real use for nepomuk which has been a plague on KDE. Recoll just works nicely niced in the background, none of the problems. Find my runner for using recoll on kde-apps site.
Unfortunately, it is now not possible to search messages within kmail without Nepomuk. Want find in message, find messages, etc., we're stuck with Nepomuk.
Even without neomuk, kmail is a mess, however.
|