Created attachment 330425[details]
screen shot
On July 10, I downloaded Gecko/2008070902.
Prior to that I had been using Gecko/2008052802 without these troubles.
Since then, numerous problems with newsgroups have (re)appeared.
This version is just not usable for reading news.
1. Some newsgroups seem to have seen only 2 messages in the last week,
even though these groups get many messages daily (as confirmed by google).
2. One group now shows that there are 12 unread messages in the folder list
pane, but the pane that lists all messages shows NO unread messages at all.
Rebuilding the newsgroup's summary file has no effect on this at all.
The filter seems to be doing some work, because new entries are being
written into the filter log, even though this version cannot display the
filter log (which is bug 446225).
I'm beginning to wonder if killed threads are causing problems.
The killed threads don't show up even when viewing all threads.
Maybe the phantom unread messages are in killed threads?
I'll attach the msf file if that will help.

The problem with groups seeming to not get any new messages that I reported
last week turned out to be due to killed threads. Those threads don't even
appear when you view->threads->all. But there is a way to display killed
threads, and when that's done, the newsgroup traffic levels appear normal.
Viewing all threads really should view ALL threads.
So, this bug is narrowed down to a single issue, the one in the subject.
A group can get into a state where the number of unread messages displayed
in the folder list pane greatly exceeds the number of unread messages
appearing in the message list pane. Rebuilding the msf file doesn't help.
The only way to get the back into sync that I was able to get to work was
to mark the whole group read, and then go and mark some messages unread
again.

(In reply to comment #1)
> A group can get into a state where the number of unread messages displayed
> in the folder list pane greatly exceeds the number of unread messages
> appearing in the message list pane.
The newsrc of said server? It's a dep-of-71728, for sure, and I'm pretty sure this is a duplicate of one of those bugs, most likely bug 79130.
Oh, by the way, we passed code freeze for a2 at least a week ago.

(In reply to comment #1)
> The problem with groups seeming to not get any new messages that I reported
> last week turned out to be due to killed threads. Those threads don't even
> appear when you view->threads->all. But there is a way to display killed
> threads, and when that's done, the newsgroup traffic levels appear normal.
> Viewing all threads really should view ALL threads.
I would tend to agree. File a spin-off bug?

I'm astonished that this regression isn't even "wanted" for TB 3!
This bug makes a major feature, "view threads with unread" useless!
Lots of threads that have no unread messages show up in that view,
listing that the number of unread messages is equal to the number of
message in the thread, even though the entire thread is read!

Created attachment 339119[details]
screen shot of view "threads with unread"
Here's a screen shot of the message list pane for a newsgroup in which
there is only one unread message, but 4 threads appear, and the apparent
count of unread messages in each thread is the same as the total number
of messages in the thread.
I've tried:
- marking the entire newsgroup as read. Had no effect on these threads.
- clicking the "Rebuild Summary File" button in the newsgroup properties.
No effect with either action.
Would it be helpful to attach a copy of the .msf file?

(In reply to comment #6)
> I'm astonished that this regression isn't even "wanted" for TB 3!
> This bug makes a major feature, "view threads with unread" useless!
In all likelihood, this isn't a regression. I reliably get threads with phantom unread messages in TB 2.
> Lots of threads that have no unread messages show up in that view,
> listing that the number of unread messages is equal to the number of
> message in the thread, even though the entire thread is read!
This bug is about the message pane count being sticky (i.e., saying 7 unread messages when there are 0 in the list pane), AIUI. Does this number get fixed when you mark the newsgroup read? Yes or No?
(In reply to comment #7)
> Would it be helpful to attach a copy of the .msf file?
No thanks, I already have a few msfs with such threads.

Created attachment 339146[details]
collapsed view of same newsgroup as above
Joshua, I seldom, if ever, saw this bug until July. Now it is very common.
This bug is about unread counts being "sticky", and as a result, the threads
appearing in views that should include only threads with unread. The serious
usability issue is the presence of entirely-read threads in that view. In
that view, where each thread is collapsed, showing only the first message in
each thread (example attached), the bogus threads are indistinguishable from
the ones with legitimate unread messages.
Was comment 7 unclear?
Marking the newsgroup read has no effect on these stuck threads.

(In reply to comment #9)
> Joshua, I seldom, if ever, saw this bug until July. Now it is very common.
It could be a previous case being hit more frequently.
> Was comment 7 unclear?
> Marking the newsgroup read has no effect on these stuck threads.
I wasn't asking about the threads--once again, this problem is documented in other bugs. I was asking about the overall newsgroup count.

It would be useful to know if this still occurs on current trunk.
Please also check whether mark-all-read (shift+C) works correctly. It's not for me in one thunderbird instances, but I think it's being caused by Nostalgy

I finally figured out how to get these f'ed up threads out of my view of
threads with unread. I ignore them. This means that if anyone ever does
post a new message to those threads I won't see it, but at least my view
of "threads with unread" is no longer filled with threads containing no unread
messages but non-zero unread counts.

This seems to be a duplicate of bug 79130 from 2001, which has a workaround (not a fix) described in bug 294754 comment #3. I used to see that bug in Thunderbird in 2005, later it more or less disappeared, but I've been seeing it again recently in SeaMonkey 2.22a1.