I have using about 7 imap resources with different accounts on differenct servers. It is GMail, Yandex, and my own server.
Also, I have using few Git resources to monitor commits on some projects.
I have noticed, that when I mark e-mails as read and wait some time, while akonadi sync collection with remote server — emails comes unread again.
Almost same thing appears when I move spam or not needed emails to trash (via Kmail, for example): it moves them, but when it syncs they appears again as unselectable (and with inactive gray color).
Previously, when I saw such behavior on akonadi — I think that it is Yandex's IMAP server bug, but then I encountered this behavior even on GMail and on my own server. Then I still believed, that this can be server-side bug (but all was okay with other imap-clients, so I start blame akonadi).
But yesterday I discovered, that akonadi has same issue on Git resource: I've marked commits as read => akonasi syncs collection => they appears as unread again.
As far as I know — git resource has only *local* storage for that and it is impossible to receive "unseen" from external server. So, now I have absolutely sure that it is akonadi bug.
P.S. I selected "major feature is broken" severity since it is absolutely impossible to use KMail/Kontact when such behavior appears.
i have the same issue with yandex (http://mail.yandex.com/) imap (akonadi-server 1.7.2, kubuntu 12.04)
Uh, yep, akonadi-server 1.7.2, KDE 4.8.2.
And, btw, this issue appeared for me even on kde 4.7.*
*** This bug has been confirmed by popular vote. ***
any devs reading kdepim-bugs? :(
Bug is still in 4.9 :(
I can confirm this issue with my cyrus imap servers. I'm subscribed to some high volume mailing lists (e.g. LKML). After a bigger number of unread mails pile up (a few thousand), it is impossible to set the seen flag on all. When you attempt this in that imap folder context menu, seen state is set on all mails in kmail UI after a while, but load persists on a very high level (usually, akonadi saturates two cores with mysql instances most of the time), then it's 4 at least. After the next mailbox scan, all messages reappear as unseen.
Needless to say, that I have to use the thunderbird mail client to fix that issue.
Sorry: kmail 4.11.4 on openSUSE 13.1 x86_64
What version of Akonadi do you have? (akonadictl --version).
If you can start Akonadi from console (akonadictl restart), do you see any warnings or errors when you try to reproduce this?
Sorry Daniel, I must have missed your questions.
> What version of Akonadi do you have? (akonadictl --version).
Still valid with: 1.13.0
> If you can start Akonadi from console (akonadictl restart), do you see any warnings or errors when you try to reproduce this?
Well, I always use the sequence: akonadictl stop; wait for all processes to terminate
e.g. ps auxww | egrep "akonadi|mysql|nepomuk|virtuoso|kmail" | grep -v grep
and akonadictl start
In that process, a lot of messages appear, but nothing stands out.
Meanwhile, I found a trick, since thunderbird takes ages to read big mailboxes, I use akonadiconsole to "Clear Akonadi Cache" on that folder. It does the trick.
I also harvested variations on the theme: set seen flag on a folder with TB, wait for finishing, but kmail keeps showing them as unread! No operation under kmail (reread folder, set folder seen) is able to solve this problem. Therefor akonadiconsole is really necessary in order to use kmail successfully in a big setting.
Sorry: KDE 4.14.3 (still openSUSE 13.1)
This bug has only been reported for versions older than KDEPIM 4.14 (at most akonadi-1.3). Can anyone tell if this bug still present?
If noone confirms this bug for a recent version of akonadi (part of KDE Applications 15.08 or later), it gets closed in about three months.
Since there is no git resource, that ported to KF5 anymore, I can test only on IMAP.
And, as far as I can see, it working pretty fine for now.
Although, when I reported that buf I had something about 200k+ letters in Inbox and something about 30-70k in some another folders. Since then I already archived many of that mail. And with current amounts I don't experience that bug anymore.