Hi,

Today Kontact started to show several issues:
* it takes quite some time for starting up
* opening mails takes a long time (i.e. displaying the content, I use IMAP with offline mode for all my mail accounts)
* sending mails takes a long time
* when entering a new calender event the calender selection drop down menu is grayed out occosionally
* when looking at the test from the akonadi settings, there is an error in ~/.local/share/akonadi/akonadiserver.error sometimes, not always

Code: Select all

Nepomuk Query Server not available
Error during executing query "INSERT INTO CollectionPimItemRelation (Collection_id, PimItem_id) VALUES (:0, :1)" :  "Duplicate entry '162-35051' for key 'PRIMARY' QMYSQL3: Unable to execute statement"


If the error is present the mail indexer of Nepomuk seems to hang at 7%

I recently upgraded to kde sc 4.11. Anyone an idea how to solve this error(s)?

Hi,

I cannot help you, but I have a similar (maybe the same) problem since I updated KDE from 4.10 to 4.11 yesterday.
When choosing an email, it takes a lot of time until the content is shown in the window - in this time an status like "Opening folder" is shown. Sending of mails costs an indefinite amount of time...
"Top" shows that mysqld takes about 50% of cpu usage, nepomuk 30% and kmail about 40% - so more than one of my four kernels is killed by the mailing program. Deleting the akonadi folder in ~/.local/share helped for starting kmail once, but now the effect has vanished. By the way: I cannot shut down kmail by closing the window - the window is closed but kmail is still running as a process in the background.
I really love akonadi, up to now it helped me to avoid a lot of wasted time -.-

Kind regards
Reinhard

Toggling the agent Akonadi Nepomuk Feeder (ANF) offline and online again and clicking 'Show task lisk' in Akonadi-Console gives:

Code: Select all

The name org.freedesktop.Akonadi.Resource.akonadi_nepomuk_feeder was not provided by any .service files

.

In the settings of the desktop search Nepomuk and its two indexers are activated and not suspended. What is weired, there is percentage displayed for 'Ready to index data' or 'Calculating Emails to index' and 'Mail is indexed' (translated back from german). The number does not change while the ANF is online or the email indexer from the desktop search kcm is unsuspended. Suspending the indexer or toggling ANF offline and online again changes the percentage, it takes some time and seems to get slower as the number gets closer to 100 %.

After reading this thread I looked for duplicates and orphaned ressources. Indeed there were several entries of akonadi-notes and though named differently they all pointed to file locations which were not existant. A check in akonadiconsole's browser confirmed that they were empty. I removed those agents.

Another thing I did was to disable the nepomuk tagging agent, as it crashed a few times before. Simultaneously a kernel upgrade had happened, so I needed to reboot anyway. Up to now it seems to help and the messages are displayed instantly and also address autocompletion is back and snappy. The issue of the hanging mail indexing percentage remains and the the error message on the duplicate entry (see above) still makes me feel that there is something wrong, that I should investigate.

Coming up is the machine of a friend, where the same symptoms occur. Let's see if those fixes help.

HmpfCBR wrote:Coming up is the machine of a friend, where the same symptoms occur. Let's see if those fixes help.

It did not. Even removing Akonadi files (~/.local/share/akonadi/, ~/.config/akonadi/ and ~/.kde/share/config/akonadi*) and starting over with a fresh configuration did only help temporarily.

The new local mails were connected to a pop3 ressource that is set to keep mails on server (imap not possible). However we did the import to get the mails that are not in the inbox, but in send folders back. In the import tool we used the option to remove duplicates. While the import basically worked the problem of "retrieving folder contents" appeared shortly afterwards.

Note that the other machine has only imap mail ressources.

The message indicates some sort of database corruption. How did you import your mails?

einar wrote:The message indicates some sort of database corruption. How did you import your mails?

Can you specify which of the messages you mean? I did import the mails by KMailCVT, i.e. "File -> Import Messages -> Import KMail Maildirs and Folder Structure". "Remove duplicate messages during import" was checked.

First sorry to answer so late. Yesterday I tried again and since then it works. What I changed this time, I created a seperate folder for importing inside the local folders and removed the old Nepomuk database (what does Nepomuk do, when ressource are deleted and recreated in akonadi?).
Also we have not finished moving all of the imported messages to their correct location in the folder structure yet. Importing we do now in smaller steps instead of moving big folders in one go (sent folder from pop3, messages already gone from the pop3 server but not from the local directory – yes I know IMAP would be a nicer solution, but I can not change that).

I asked because there are now different ways to import mails into KMail, and not all of them use kmailcvt. That said, glad to hear you're making progress.

With regards to your Nepomuk question, recreating a resource unfortunately forces a total reindexing (due to the fact that there is no "prior knowledge" of what the old resorce was compared to the new).

einar wrote:With regards to your Nepomuk question, recreating a resource unfortunately forces a total reindexing (due to the fact that there is no "prior knowledge" of what the old resorce was compared to the new).

That is O.K. I rather have an correctly indexed ressource than a corrputed one. I was merely asking because removing the Nepomuk database before creating new ressources and importing was one of the things I changed, so I suspected a causal relationship.

Apart from that I have to say the mail indexing went quite fast. By now all mails are sorted, there have been reboots and no issues araised. Looks like the problem is solved, though I am not sure what the solution was.

The machine on which I originally had the problem and could solve it earlier still gets the "Duplicate entry '162-35051' for key 'PRIMARY' QMYSQL3:" (see first post) error in the Akonadi test. I guess to figure out which item is the duplicate and remove it/give it a new ID I need to stop Akonadi, connect to the database and do it manually?

I will ask the developers just in case.