when nepomuk is nurring I get the above message when trying to open mails. the mails files are stored locally and accessed with no problem. the message appears for a long timec(minutes) and then the mail appear, and the same will happen fr every other mail. this is happenning almost allways regardless of the mail content, even short plain text email get stuck. Reproducible: Sometimes Steps to Reproduce: 1.open kmail 2.choose mail to view 3.wait message Actual Results: long waiting for message view Expected Results: immediate view of the message when disabling nepomuk it seems to help after some time. thanks.
I have tried running kontact from shell and saw the next message while the blue screen of waiting was displayed: kontact(29786) MessageViewer::ContactDisplayMessageMemento::slotSearchJobFinished: Unable to fetch contact: "Unable to fetch item from backend (collection 0) : Unable to retrieve item from resource: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken." hope that helps
ContactDisplayMessageMemento use nepomuk so if there is a pb here and you disable nepomuk if will help you. Will look at why it's too slow.
yes, I have noticed that disabling nepomuk sort of workaround the problem, but I do need nepomuk running... thanks
I have this issue too. And disable nepomuk does not work. In the console, I see lots of "Unknown error" after closing kmail.
I have removed the akonadi database (~/.local/share/akonadi) and things move way way faster now. my guess is my database got corrupted over the years...
I see very high kmail and mysql usage. If I get bored waiting for a message to open and quit kmail, then on restarting it, it immediately crashes. Thereafter it refuses to open at all until I log out and back in. kmail is virtually unusable.
happened here again, on one of the imaps accounts. behaviour seems random. akonadictl restart took very long, killing kmail probably helped. after akonadictrl restart kmail worked ok again. looks like somehow a socket/session gets stuck sometimes.
I have the same problem. My message folder is local. Is there a solution yet?
A workaround is to read mail in Akonadi console.
Hi, Yesterday, I upgraded from opensuse 12.3 to 13.1, and kmail(4.11.3) was blocked opening messages with similar messages about the message being loaded. The system was using a lot of cpu for kmail, akonadi and mysql. Looking for a solution I found this bug report that looked like my issue. But the solution to fix my issue was in https://bugs.kde.org/show_bug.cgi?id=322958 I summarize, but you can read the other bug report. run akonadiconsole in tab Browser look for duplicate entries, for me all were duplicated (Inbox, Outbox, Templates...) and remove the duplicate ones, but only the ones that are empty. Then I launched again kmail and it was fine. Can you check if this workaround fixes your issue? This would mean this bug entry is a duplicate. Cheers
Thank you DjVB for your report and to all the commenters. It is about a version of KMail which uses Nepomuk and is unmaintained. Thus closing. If you still see performance issues please open new reports. But please follow the following guide lines to avoid unnecessary work for the developers: - Ideally test with KDEPIM and Akonadi 15.08. It contains some performance improvements like the binary protocol. - Otherwise at least use KDEPIM 4.14.10 and newest Akonadi 1.13 you can get as it already contains some performance improvements. - If you can wait, please retest with KDEPIM and Akonadi 15.12 once they become available for you. Akonadi 15.12 will contain *massive* performance improvements implemented by Dan due to new database indexes, optimized queries and leveled file_db directory. All of these are in master already, so if you dare use kdesrc-build to compile KF5, kdepim and kdepim-runtime. I am using this currently and it basically moves the bottleneck to KMail (slow threading for example). It is a *huge* improvement. Thank you and greetings from KDE Randa Meetings, Martin