Bug 333798 - KMail: Number of indexed emails doesn't match number of emails
Summary: KMail: Number of indexed emails doesn't match number of emails
Status: RESOLVED WORKSFORME
Alias: None
Product: Akonadi
Classification: Frameworks and Libraries
Component: Indexer (show other bugs)
Version: unspecified
Platform: unspecified Linux
: NOR normal
Target Milestone: ---
Assignee: kdepim bugs
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-04-23 23:27 UTC by Albert Astals Cid
Modified: 2022-12-21 05:18 UTC (History)
4 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Albert Astals Cid 2014-04-23 23:27:34 UTC
Data from the right mouse button -> properties -> maintainance

Inbox: 74376 messages, 75003 indexed messages
Sent: 71166 messages, 71162 indexed messages
trash: 13638 messages, 12422 indexed messages
kde-core-devel: 48386 messages, 48422 indexed messages

Any idea how to fix that? Please don't suggest a removal of the index because i've done that a few times already and doesn't seem like a good idea :D
Comment 1 Jochen Trumpf 2014-05-15 06:01:11 UTC
I have the same issue on gentoo with kde-base/baloo 4.13.0

I had all my emails (~80k) indexed in nepomuk, and when upgrading to the first kde version with baloo (4.12.1? can't remember now) those were properly migrated. They are still indexed. Of all the emails that have arrived since, only some are indexed. 

I have checked bug #332196 and my version contains the X-Akonadi-Custom-HasLocalStorage fix (I am using local maildirs).

My inbox folder shows many more emails as indexed than are currently contained in the folder. Could it be that things go wrong when emails get moved between folders?

I am not sure if this is relevant, but in order to get all emails indexed in nepomuk I had to manually force multiple retrievals per email (with a little script I wrote for that purpose). I now believe that was related to the cacheTimeout issue mentioned in bug #332196. What I observed in that process, though, sometimes the re-index failed regardless and only several retrieval repeats would fix that. I simply did 5 repeats per akonadi item in my script to get it done (it only took about 120 hours ;0). I did not try to track down the core issue at the time. It is possibly a timing issue. I am running inside a virtualbox so file i/o can be VERY slow sometimes. 

Is there a way to manually force a re-index of a particular akonadi item in baloo? With nepomuk I called org.freedesktop.Akonadi.Resource.requestItemDeliveryV2 while the feeder was running. Should that still do the job? I am happy to help debug this if you tell me where to look.
Comment 2 piedro 2016-03-29 10:35:37 UTC
Same here on Arch fully updated kmail 5.1.3, KF 5.20, QT 5.6 ... 

All my local folders are completely indexed but none of the Imap ones are. 
1922 mails, only 277 indexed, something like that for every single folder. 

Restarting the akonadi indexer via akonadi console doesn't change anything. Switching off full text index for the folder and turning it on doesn't change anything. 

How can this not get more attention? Any incomplete index poses a severe problem to searching within mails - imho breaks it entirely. 

Please at least comment. 

thx, piedro
Comment 3 piedro 2016-04-07 13:18:02 UTC
If one enables offline reading for Imap - 
and then unsubsribes to every single folder - 
than under "server subsciptions" re-subscribes to all folders again - 
now the folders get subscibed and while getting downloaded they get indexed... 

Thing is, now MOST of the mails get indexed but not all of them I get things like 
 
inbox containing 212 mails , indexed 201 

so about every folder has a few mails missing! 

This is bad! If there is missing mail in the index you can't use the search in any critical workflow. 

Also there is no indication whatsoever which mails are indexed iand which aren't - so I do not even know which of my mails are included in a fulltext search and which are not. 

Also I think it's not a very good habit to not answer or react to bug reports at all. 

Soon no one will do any reports anymore since it's pointless in most cases. 
Then you, the devs, have to do your own testing  again. 

ty, p.
Comment 4 Justin Zobel 2022-11-21 08:21:55 UTC
Thank you for reporting this issue in KDE software. As it has been a while since this issue was reported, can we please ask you to see if you can reproduce the issue with a recent software version?

If you can reproduce the issue, please change the status to "REPORTED" when replying. Thank you!
Comment 5 Bug Janitor Service 2022-12-06 05:16:23 UTC
Dear Bug Submitter,

This bug has been in NEEDSINFO status with no change for at least
15 days. Please provide the requested information as soon as
possible and set the bug status as REPORTED. Due to regular bug
tracker maintenance, if the bug is still in NEEDSINFO status with
no change in 30 days the bug will be closed as RESOLVED > WORKSFORME
due to lack of needed information.

For more information about our bug triaging procedures please read the
wiki located here:
https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging

If you have already provided the requested information, please
mark the bug as REPORTED so that the KDE team knows that the bug is
ready to be confirmed.

Thank you for helping us make KDE software even better for everyone!
Comment 6 Bug Janitor Service 2022-12-21 05:18:55 UTC
This bug has been in NEEDSINFO status with no change for at least
30 days. The bug is now closed as RESOLVED > WORKSFORME
due to lack of needed information.

For more information about our bug triaging procedures please read the
wiki located here:
https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging

Thank you for helping us make KDE software even better for everyone!