GNOME Bugzilla – Bug 251045
Unread count not updated.
Last modified: 2013-09-10 14:03:17 UTC
Please fill in this template when reporting a bug, unless you know what you are doing. Description of Problem: Unread count not updated after reading messages. Steps to reproduce the problem: 1. Have a folder with some unread messages 2. Read them 3. Count is not updated Actual Results: Expected Results: How often does this happen? Additional Information: Changing folders, expunging or send / receive have no effect. Mailer seems not to be updating flags: protocol: received: * 36067 FETCH (UID 46918 FLAGS ()) received: * 36068 FETCH (UID 46919 FLAGS ()) received: * 36069 FETCH (UID 46920 FLAGS ()) received: * 36070 FETCH (UID 46921 FLAGS ()) received: * 36071 FETCH (UID 46922 FLAGS ()) received: * 36072 FETCH (UID 46923 FLAGS ()) received: * 36073 FETCH (UID 46924 FLAGS ()) received: * 36074 FETCH (UID 46925 FLAGS ()) received: * 36075 FETCH (UID 46926 FLAGS ()) received: * 36076 FETCH (UID 46927 FLAGS ()) received: * 36077 FETCH (UID 46928 FLAGS ()) received: * 36078 FETCH (UID 46929 FLAGS ()) received: * 36079 FETCH (UID 46930 FLAGS ()) received: * 36080 FETCH (UID 46931 FLAGS ()) received: * 36081 FETCH (UID 46932 FLAGS ()) received: * 36082 FETCH (UID 46933 FLAGS ()) received: A00432 OK FETCH completed. sending : A00433 NOOP received: A00433 OK NOOP completed Reading a message cause no debug output. UNSEEN count for this folder matches count.
This was 20031114 build Still fails with 20031116 build
*** bug 251080 has been marked as a duplicate of this bug. ***
*** bug 251219 has been marked as a duplicate of this bug. ***
*** bug 251320 has been marked as a duplicate of this bug. ***
*** bug 251074 has been marked as a duplicate of this bug. ***
retargetting 1.5 target milestone reports -> 1.5.1 Sorry for the spam
this is important, if you hae more then 1 folder to read it makes the mailer an unhappy experience.
implemented.
*** bug 252973 has been marked as a duplicate of this bug. ***
you can't tell me this is fixed jeff?
This is still happening in a CVS build from a couple of days ago. I watch it issue STATUS and get told there are unseen messages in a folder, and the folder in the tree doesn't change; it still looks like there are no new messages in it.
*** bug 252974 has been marked as a duplicate of this bug. ***
Unread counts isn't working properly for local folders, either. When I start evolution-1.5 though, I just noticed that I get a bunch of spew from the mailer... can't set unread count for '/Inbox' - path unknown. can't set unread count for '/Drafts' - path unknown. can't set unread count for '/Outbox' - path unknown. can't set unread count for '/Sent' - path unknown. can't set unread count for '/Inbox' - path unknown. added '/Inbox' to path_hash added '/Drafts' to path_hash added '/Outbox' to path_hash added '/Sent' to path_hash Perhaps this will be helpful, Jeff?
fixed in CVS now
I am using 1.5.3 and a bunch of IMAP folders behind courier-imap 1.6.2 and this is still an issue. The unread counts are updated on the initial folder scan but not on any consequent background check or explicit Send/Receive
Jeff: this is not fixed, NotZed opened a new one.
*** bug 253450 has been marked as a duplicate of this bug. ***
ok, I thought the problem was only on initial population of the folder-tree since that's what the people here at the office were complaining about. updating unread counts when new mail arrives seems to actually work for me with imap/pop do you guys get errors on the console about the folder path not existing when new mail arrives? (kinda like the errors dobey pasted)
Strangely I cannot reproduce this reliably but here is how it goes: I have this virii folder that these (Mydoom) days gets a new mail approximately every 10-15 seconds. -> Focus it -> Ctrl-A -> Ctrl-K -> move to some other folder (the virii folders shows no underad messages) -> wait a minute or so -> F9 - when finished the virri folder still shows no underad messages -> focus it, the unread count immediately goes to 5-6 No messages on the console
this sounds more likely that the STATUS command that IMAP is sending to the server is getting a response of 0 but I'll need CAMEL_VERBOSE_DEBUG output to know for sure.
gekker on irc explained what the bug was - basically, if you have the folder structure: Inbox Foo Bar but have not yet expanded the Inbox node yet, then if we get nnnotified that Foo contains new mail, Inbox would not bold. the code now recursively loads the entire folder tree (just like 1.4 did) so that this is no longer a problem.
bloody hell. still isn't fixed afterall. was just using imap and the unread counts weren't going down as I read my mail.
*** bug 253808 has been marked as a duplicate of this bug. ***
btw this has nothing to do with imap, even though it might also happen with imap.
*** bug 253804 has been marked as a duplicate of this bug. ***
i'm gonna have a poke at this, since it doesn't seem to be getting anywhere.
ok, i've done some fixes for this. although from some of the reports above, it might not address the imap case.
*** bug 254416 has been marked as a duplicate of this bug. ***
I can confirm this still occurs with imap (though not all the time) on version 1.5.4
yea, we know - the fix went in *after* 1.5.4 as released :-)
er, meant to close
*** bug 254995 has been marked as a duplicate of this bug. ***
This is still happening in the CVS version (checked out today) that I'm running at the moment - The folder counts are being updated better than they were - the number of unread messages goes down when emails are read, the folder count sometimes updates when a send/receive happens, but there still seem to be issues with subfolders.
Investigated a little more - my problem is exactly the same as Yanko Kaneti describes above, though like he says, it is not reproducable reliably. Sometimes the folder count does update with new mail, sometimes it doesn't. Focusing the folder always works and updates the count with new mail.
Simon: if you set the CAMEL_VERBOSE_DEBUG environment before running evolution from that shell, can you watch output being dumped to the xterm? try seeing if evo is getting responses indication that folder XYZ has unread mail that evo is not then updating the folder-tree with. should see something like: sending : A##### STATUS XYZ (UNSEEN) received: * STATUS XYZ (UNSEEN #) received: A##### OK STATUS if folder XYZ isn't being updated to display # as the unread count, then there is still a bug. If not, then there is no bug.
Right - Have checked this: I see the following in the output: sending : A02828 STATUS gentoo-dev (UNSEEN) received: * STATUS "gentoo-dev" (UNSEEN 12) received: A02828 OK Status completed. But evolution screen is still showing gentoo-dev(10)
Reopening from last comments.
can you turn on the unread debug in mail/em-folder-tree-model.c? near the top of the file, change #define u(x) to #define u(x) x and recompile. note that the above #define is only in the latest gnome cvs, it will take a while to filter through to public/tarballs. (i'm not sure this will show anything, but hopefully it will).
I can't see anything obvious in the terminal with this new option on and CAMEL_VERBOSE_DEBUG also specified. Just getting similar output to before: sending : A02669 STATUS freebsd-current (UNSEEN) received: * STATUS "freebsd-current" (UNSEEN 84) received: A02669 OK Status completed. Evolution is still saying 76, click on the folder - and it updates. Something of interest maybe, after clicking on the folder, i get: set unread count 0x8177788 '/freebsd-current' 84 appear in the terminal.
You should get a bunch of other stuff in the terminal. like 'set unread count xxx xxx' for all your folders, among other stuff. attach it all please.
*** bug 255109 has been marked as a duplicate of this bug. ***
Like I said above, I'm simply not seeing those messages when I do a send/receive or it is done automatically - unless I click on the folder then I get the: set unread count 0x8177788 '/freebsd-current' 118 messages that you are expecting.
*** bug 255183 has been marked as a duplicate of this bug. ***
If I hit Send/Receive with unread debug and CAMEL_VERBOSE_DEBUG, I see lines like: sending : A00057 STATUS INBOX.Family (UNSEEN) received: * STATUS "INBOX.Family" (UNSEEN 1) However, the UI is not actually updated to reflect this unless I either have that folder currently open or I click on it.
I do see the "set unread count 0x818c938 '/INBOX/Family' 3" style messages only when I actually click on the folder, incidentally.
well attach everythign printed out then. like, all of it.
Created attachment 43362 [details] full log from evolution receiving/sending imap folders
This is from pressing Send/Receive. There is a new message in the "Family" folder; the unread count in the UI is not updated: sending : A00043 LIST "" INBOX received: * LIST (\Unmarked \HasChildren) "." "INBOX" received: A00043 OK LIST completed. sending : A00044 LIST "" INBOX.WM-Spec received: * LIST (\HasNoChildren) "." "INBOX.WM-Spec" received: A00044 OK LIST completed. sending : A00045 LIST "" INBOX.System received: * LIST (\HasNoChildren) "." "INBOX.System" received: A00045 OK LIST completed. sending : A00046 LIST "" INBOX.Spam received: * LIST (\HasNoChildren) "." "INBOX.Spam" received: A00046 OK LIST completed. sending : A00047 LIST "" INBOX.Gnome-hackers received: * LIST (\HasNoChildren) "." "INBOX.Gnome-hackers" received: A00047 OK LIST completed. sending : A00048 LIST "" INBOX.Desktop-devel received: * LIST (\HasNoChildren) "." "INBOX.Desktop-devel" received: A00048 OK LIST completed. sending : A00049 LIST "" INBOX.Debian-gtk-gnome received: * LIST (\HasNoChildren) "." "INBOX.Debian-gtk-gnome" received: A00049 OK LIST completed. sending : A00050 LIST "" INBOX.Bugzilla received: * LIST (\HasNoChildren) "." "INBOX.Bugzilla" received: A00050 OK LIST completed. sending : A00051 LIST "" INBOX.Family received: * LIST (\HasNoChildren) "." "INBOX.Family" received: A00051 OK LIST completed. sending : A00052 LIST "" INBOX.Trash received: A00052 OK LIST completed. sending : A00053 STATUS INBOX (UNSEEN) received: * STATUS "INBOX" (UNSEEN 0) received: A00053 OK STATUS Completed. sending : A00054 STATUS INBOX.Bugzilla (UNSEEN) received: * STATUS "INBOX.Bugzilla" (UNSEEN 0) received: A00054 OK STATUS Completed. sending : A00055 STATUS INBOX.Debian-gtk-gnome (UNSEEN) received: * STATUS "INBOX.Debian-gtk-gnome" (UNSEEN 0) received: A00055 OK STATUS Completed. sending : A00056 STATUS INBOX.Desktop-devel (UNSEEN) received: * STATUS "INBOX.Desktop-devel" (UNSEEN 0) received: A00056 OK STATUS Completed. sending : A00057 STATUS INBOX.Family (UNSEEN) received: * STATUS "INBOX.Family" (UNSEEN 1) received: A00057 OK STATUS Completed. sending : A00058 STATUS INBOX.Gnome-hackers (UNSEEN) received: * STATUS "INBOX.Gnome-hackers" (UNSEEN 0) received: A00058 OK STATUS Completed. sending : A00059 STATUS INBOX.Spam (UNSEEN) received: * STATUS "INBOX.Spam" (UNSEEN 34) received: A00059 OK STATUS Completed. sending : A00060 STATUS INBOX.System (UNSEEN) received: * STATUS "INBOX.System" (UNSEEN 0) received: A00060 OK STATUS Completed. sending : A00061 STATUS INBOX.WM-Spec (UNSEEN) received: * STATUS "INBOX.WM-Spec" (UNSEEN 0) received: A00061 OK STATUS Completed. Now, clicking on the "Family" folder: sending : A00062 SELECT INBOX.Family received: * FLAGS (\Draft \Answered \Flagged \Deleted \Seen \Recent) received: * OK [PERMANENTFLAGS (\* \Draft \Answered \Flagged \Deleted \Seen)] Limited received: * 1 EXISTS received: * 1 RECENT received: * OK [UIDVALIDITY 1077246210] Ok received: A00062 OK [READ-WRITE] Ok sending : A00063 UID FETCH 1:* (FLAGS RFC822.SIZE INTERNALDATE BODY.PEEK[HEADER.FIELDS.NOT (RECEIVED)]) received: * 1 FETCH (UID 8 FLAGS (\Recent) RFC822.SIZE 702 INTERNALDATE "05-Mar-2004 10:04:30 -0800" BODY[HEADER.FIELDS.NOT ("RECEIVED")] {499} received: ) received: A00063 OK FETCH completed. set unread count 0x818a0a8 '/INBOX/Family' 1
Not 100% sure if this is related, but I have just experienced some problems with evolution freezing when switching between IMAP folders - The following messages repeated: received: * 187 FETCH (UID 2111 FLAGS (\Seen)) received: * 188 FETCH (UID 2112 FLAGS (\Seen)) received: * 189 FETCH (UID 2113 FLAGS (\Seen)) received: * 190 FETCH (UID 2114 FLAGS (\Seen)) received: * 191 FETCH (UID 2115 FLAGS (\Seen)) received: * 192 FETCH (UID 2116 FLAGS (\Seen)) received: * 193 FETCH (UID 2117 FLAGS (\Seen)) received: * 194 FETCH (UID 2118 FLAGS (\Seen)) received: * 195 FETCH (UID 2119 FLAGS (\Seen)) received: * 196 FETCH (UID 2120 FLAGS (\Seen)) received: * 197 FETCH (UID 2121 FLAGS (\Seen)) received: * 198 FETCH (UID 2122 FLAGS (\Seen)) received: * 199 FETCH (UID 2123 FLAGS (\Seen)) received: * 200 FETCH (UID 2124 FLAGS (\Seen)) received: * 201 FETCH (UID 2125 FLAGS (\Seen)) received: * 202 FETCH (UID 2126 FLAGS (\Seen)) received: * 203 FETCH (UID 2127 FLAGS (\Seen)) through to received: * 1196 FETCH (UID 3120 FLAGS ()) received: * 1197 FETCH (UID 3121 FLAGS ()) received: * 1198 FETCH (UID 3122 FLAGS (\Seen)) received: * 1199 FETCH (UID 3123 FLAGS ()) received: * 1200 FETCH (UID 3124 FLAGS ()) received: * 1201 FETCH (UID 3125 FLAGS ()) received: * 1202 FETCH (UID 3126 FLAGS ()) received: * 1203 FETCH (UID 3127 FLAGS (\Seen)) received: * 1204 FETCH (UID 3128 FLAGS ()) received: * 1205 FETCH (UID 3129 FLAGS ()) received: * 1206 FETCH (UID 3130 FLAGS ()) received: * 1207 FETCH (UID 3131 FLAGS ()) received: * 1208 FETCH (UID 3132 FLAGS ()) received: * 1209 FETCH (UID 3133 FLAGS ()) received: * 1210 FETCH (UID 3134 FLAGS ()) received: * 1211 FETCH (UID 3135 FLAGS ()) received: * 1212 FETCH (UID 3136 FLAGS ()) received: * 1213 FETCH (UID 3137 FLAGS ()) received: * 1214 FETCH (UID 3138 FLAGS ()) received: * 1215 FETCH (UID 3139 FLAGS ()) received: * 1216 FETCH (UID 3140 FLAGS ()) received: * 1217 FETCH (UID 3141 FLAGS ()) received: * 1218 FETCH (UID 3142 FLAGS ()) received: * 1219 FETCH (UID 3143 FLAGS ()) received: * 1220 FETCH (UID 3144 FLAGS (\Seen)) received: * 1221 FETCH (UID 3145 FLAGS ()) received: * 1222 FETCH (UID 3146 FLAGS ()) received: * 1223 FETCH (UID 3147 FLAGS ()) received: * 1224 FETCH (UID 3148 FLAGS ()) received: * 1225 FETCH (UID 3149 FLAGS (\Seen)) received: * 1226 FETCH (UID 3150 FLAGS ()) received: * 1227 FETCH (UID 3151 FLAGS ()) received: * 1228 FETCH (UID 3152 FLAGS (\Seen)) received: * 1229 FETCH (UID 3153 FLAGS (\Seen)) received: * 1230 FETCH (UID 3154 FLAGS ()) received: * 1231 FETCH (UID 3155 FLAGS (\Recent)) received: A00149 OK Fetch completed. set unread count 0x8177dd8 '/gentoo-dev' 69 This seems to imply I have a mail box with over 1000 messages... which isn't the case. It then "freezes" with high CPU usage (constantly) and all the GUI greyed out.
*** bug 255838 has been marked as a duplicate of this bug. ***
I don't really know why this bug is in NEEDINFO state. However, this bug does appear in recent builds to be, if not fixed, greatly mitigated.
Sorry to once again bring up this bug. But I am still having problems. The unread count is updating fine when I read messages - but it is still not updating when subfolders on the IMAP server receive mail. To test this I opened both 1.5.5 and 1.4.6 simultaneously, sent an email using mutt - and sure enough, 1.4.6 detected this and the unread count updated to 1 in the subfolder. 1.5.5 did nothing - even when I pressed the send/receive button. The IMAP server i'm running is dovecot 0.99.10.4.
Forgot to add - there appears to be no problem at all with new email arriving in the INBOX on the imap server.
is this with the 1.5.5 *release* or the current snapshots of the soon-to-be-1.5.6 ?
1.5.5 Release - I assume. I'm using the packages in debian experimental.
ah, okay - that would be why you are seeing the bug then :-)
I hate to reopen this again - but I'm still having issues. The updating of unread counts appears to work *perfectly* when you first open evolution, but if it has been open for a while - it reverts back to only updating when you click on the folder. (This is on an IMAP account).
you need to check the box that says "check all folders for new mail" otherwise it is expected that you will get the behaviour you are seeing. we walked thru this bug with someone else this very morning and discoveed that was the problem.
I do have this box checked, and it does work, for a while. But after evolution has been running for a while, it appears to "lose" this option and only check the folders when they are clicked on.
well, it works for me. upgrade to a recent snapshot