Bug 860504 - Number of unread messages not increased for inbox, no mail notification
Summary: Number of unread messages not increased for inbox, no mail notification
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: evolution
Version: 17
Hardware: x86_64
OS: Linux
unspecified
medium
Target Milestone: ---
Assignee: Matthew Barnes
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2012-09-26 02:10 UTC by Bojan Smojver
Modified: 2013-06-12 13:40 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2013-06-12 13:40:04 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)
Screenshot of the problem (63.30 KB, image/png)
2012-10-22 21:24 UTC, Bojan Smojver
no flags Details

Description Bojan Smojver 2012-09-26 02:10:03 UTC
Description of problem:
Number of unread messages is not increased on mail delivery to inbox. This mysteriously stopped working today. I removed all the cached mail after killing all evo processes, but to no avail. Subfolders are still being treated properly.

Version-Release number of selected component (if applicable):
evolution-3.4.4-2.fc17.x86_64

How reproducible:
Always.

Steps to Reproduce:
1. Send yourself an e-mail.
2. See it hit Evo's inbox.
3. Could of unread on folder (inbox) not increased. No notification.
  
Actual results:
Count of unread messages busted. Not sure what changed, but it seems like some data file somewhere is out of whack.

Expected results:
Worked fine until today.

Additional info:
Same for evolution-3.4.4-1.fc17.x86_64, so not affected by most recent RPM.

Comment 1 Bojan Smojver 2012-09-26 02:21:43 UTC
folders.db in .cache has this after getting a fresh email:
-----------------
sqlite> SELECT * FROM folders WHERE folder_name='INBOX';
  folder_name = INBOX
      version = 14.0
        flags = 0
      nextuid = 0
         time = 0
  saved_count = 20
 unread_count = 1
deleted_count = 0
   junk_count = 0
visible_count = 20
    jnd_count = 0
        bdata = 4 1111895052 13449 11609
-----------------

And yet, no notification and inbox is not in bold in the folder list and does not have (1) next to it. Confused...

This is all with IMAP+, if it matters. I have another Evo running against EWS and it has no trouble.

PS. A subfolder receiving an e-mail shows unread_count of 1 in sqlite and does the bold/count bit too.

Comment 2 Milan Crha 2012-10-22 16:08:35 UTC
Thanks for a bug report. I suppose this didn't fix on its own meanwhile. The issue might be recent change in evolution-data-server, those introduced in 3.4.4, thus maybe downgrading to 3.4.3 will fix the issue temporarily.

The information about the account type being IMAP+ is important, as it makes things less confusing.

If I read it right, then the Inbox doesn't have a special icon in folder list too, like the On This Computer/Inbox folder, it has a standard icon for a folder instead, right?

That may explain the new mail folder notifications, though not the unread count changes. I'll try to investigate further here and let you know if I find anything.

Comment 3 Bojan Smojver 2012-10-22 21:24:46 UTC
Created attachment 631751 [details]
Screenshot of the problem

No notification when this e-mail arrived. Folder not in bold and unread count on the folder not increased.

Comment 4 Bojan Smojver 2012-10-22 23:09:27 UTC
Reverting to:
------------------
evolution-data-server-3.4.1-2.fc17.x86_64.rpm
evolution-3.4.1-2.fc17.x86_64.rpm
------------------

Did not improve things.

I'm having a strong suspicion that this (wrong count) is hidden in some data/config file somewhere. I just do not know where.

Comment 5 Milan Crha 2012-10-23 08:04:15 UTC
Thanks for the update. I see it is properly identified as Inbox, which is good. I also see that the window title, same as the line above the folder tree says "Inbox 1 unread, 12 total", thus this part is able to read unread messages properly, only folder tree, which reads unread counts from elsewhere, shows wrong value.

If the downgrade didn't help, then even better, we know this was not caused by any recent changes (in 3.4.4). I would update back to 3.4.4, to have the most recent code.

Now the interesting part about notifications, there are two new mail notification softwares, one is a built-in plugin, which you can configure in Edit->Plugins->Mail Notification->tab Configuration. The other is a 3rd party package mail-notification, I've no idea about, unfortunately.

I guess you use the built-in plugin, which might mean the issue is same as with the folder tree. If the underlying data got confused for some reason, maybe after some crash, then the easiest way is to delete (move away) whole local cache of your IMAP+ account, the folder where folders.db file from comment #1 is. Do that with evolution being stopped and the next start it'll re-download folder structure and its content. The disadvantage is that the whole cache and message list will be downloaded again, which takes its time (and band-width).

Comment 6 Bojan Smojver 2012-10-23 21:24:48 UTC
(In reply to comment #5)
 
> Now the interesting part about notifications, there are two new mail
> notification softwares, one is a built-in plugin, which you can configure in
> Edit->Plugins->Mail Notification->tab Configuration. The other is a 3rd
> party package mail-notification, I've no idea about, unfortunately.

I use the built-in plugin.

> I guess you use the built-in plugin, which might mean the issue is same as
> with the folder tree. If the underlying data got confused for some reason,
> maybe after some crash, then the easiest way is to delete (move away) whole
> local cache of your IMAP+ account, the folder where folders.db file from
> comment #1 is. Do that with evolution being stopped and the next start it'll
> re-download folder structure and its content. The disadvantage is that the
> whole cache and message list will be downloaded again, which takes its time
> (and band-width).

Yeah, I did that already (see comment #0). It did not help. That is what got me really baffled...

Is there some other place where this number is kept?

Also (and more importantly), how/why is it kept in two places? Obviously, one count is correct...

Comment 7 Bojan Smojver 2012-10-24 05:28:55 UTC
Just to be sure, stopped evo (all processes), blew away stuff in .cache and .local/share. No change.

Comment 8 Bojan Smojver 2012-10-24 09:55:19 UTC
Just recreated that account in Evo. Same. Totally baffling...

Comment 9 Milan Crha 2012-10-24 11:22:36 UTC
There are two places, because one is the store, which holds list of folders (and some basic information like total count and unread count on each folder), and the the folder object itself, which is using folder summary. That's what is stored in folders.db file, and from where the top line reads the counts, if I recall correctly. These two values are supposed to be kept in sync since 3.4.x, but it seems like the UI part is still doing some magics on unread counts.

Because it happened suddenly, and you verified that downgrade of evolution has no influence on it, then I cannot think of anything else than some update broke this. It is, apparently, quite unlikely, as long as we speak of evolution* packages. Same strange thing is when you re-enter the account from scratch. Does the same happen with a brand new user account? I'm getting out of idea, not mentioning that this works for me as expected, as far as I can tell.

Comment 10 Bojan Smojver 2013-01-11 23:20:14 UTC
In F-18, I do get notification for inbox delivered messages. Will keep an eye on count, but things appear to be looking better.


Note You need to log in before you can comment on or make changes to this bug.