User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030529 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030529 Haven't read or used the ms news groups in probably over a month. I entered last week and I never have time to go through a small fraction, but many of the news groups have an unread count that is negative! As I look, for example m.p.w.dns says -1336 for unread out of 7441 total. While m.p.w.general (I think that might be windows xp), says unread=100209, read=98564. If I click on the news group, it will update the Unread count to something 'normal' -- a bolded positive number. But I guess I'm a bit confused with the non-bolded negative count for unread. Does that mean I've really read that many? (negative unread = positive read?) Reproducible: Always Steps to Reproduce: 1.subscribe to newsgroups on ms server -- maybe high volume helps but dunno 2.don't read news for a month or so, then go back in and see if it happened 3. Heck if I know...they were never negative before when I was more regularly reading the news groups. Expected Results: I dunno....since I don't know what the negative number signifies -- maybe the latest news article on the server has wrapped? Not all groups have negative numbers -- some were displayed "normally" even though I didn't enter them -- m.p.p.shell, forexample says 528/1268....*OUCH*...now this hurts As i sat here typing, all the groups just updated with positive bolded numbers except 1 - m.p.p.security still has a negative number (1419/254) .. oops 2 of them...m.p.w.security also has negative -6071/741. Very weird. All looks normal now except for two microsoft security groups....what's amusing about this picture....:-) still don't know what is causing it sigh...

I've seen this some times, too (with Win2k). I suspect "shooting" Mozilla (either via explicit kill or crash) if MailNews is open and there are unread mails in a group as the cause, but haven't been able to reproduce this, either.

This is a duplicate of a bug I filed #205879. I see this problem frequently. It needs to be addressed.

*** Bug 205879 has been marked as a duplicate of this bug. ***

I have seen this forever on every Windows OS, not just XP, going all the way back to Moz pre-1.0 versions. It just looks bad. Seriously, how can there be a negative number of messages unread? At the very least the displayed value should be changed to "unknown" when a negative number is the result of whatever calculation tries to figure out the value.

I'm still not quite sure under which circumstances this occurs. But I've attached a screen shot showing the negative count and the real values that appear as soon as the NG is selected.

Your picture illustrates exactly what I've seen. It seems to happen in 2 situations (on Windows anyway). The first is when MailNews (Moz & Tbird) is not shut down properly. Open a news server and let the new messages get noted. Then hit your system reset button. After re-boot is complete, opening up the same news server will show negative numbers IF new messages have been posted. The second situation is when I haven't looked at the news server for a week or so. It has to be related to a counter overflow somewhere.

Here's what my list looks like after not accessing this particular news server for about a week.

*** Bug 220802 has been marked as a duplicate of this bug. ***

On User-Agent Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7a) Gecko/20040124 I also see this. Any high traffic group, such as binaries groups where the entire group cycles through in hours or days, will exhibit this behavior. I've gone into groups, marked them read, and a couple of days later they show up as negative numbers. It seems that if the first available article number is greater than the last number you read, the unread count goes negative.

So, following the logic from Comment #9, I get to nsNNTPNewsgroupList::GetRangeOfArtsToDownload in mozilla/source/mailnews/news/src/nsNNTPNewsgroupList.cpp where the line of code rv = args->SetArticleCount(*last - *first + 1); appears, and seems to agree with the hypothesis.

(In reply to comment #10) > So, following the logic from Comment #9, I get to > nsNNTPNewsgroupList::GetRangeOfArtsToDownload in > mozilla/source/mailnews/news/src/nsNNTPNewsgroupList.cpp where the line of code > rv = args->SetArticleCount(*last - *first + 1); appears, and seems to agree with > the hypothesis. This is the problem then - that line is clearly wrong.. it fails not only on rewrap, but on any newsgroup that has deleted messages between the first and last... it explains why you get bogus positive values too (a longstanding bug that has been there since the first versin of mozilla I ever used.. see bug 71728). When you click on the newsgroup it gets the correct value, so clearly it's possible to get the correct value.

see also bug 290826.(In reply to comment #11) > (In reply to comment #10) > > So, following the logic from Comment #9, I get to > > nsNNTPNewsgroupList::GetRangeOfArtsToDownload in > > mozilla/source/mailnews/news/src/nsNNTPNewsgroupList.cpp where the line of code > > rv = args->SetArticleCount(*last - *first + 1); appears, and seems to agree with > > the hypothesis. > This is the problem then - that line is clearly wrong.. it fails not only on > rewrap, but on any newsgroup that has deleted messages between the first and > last... > When you click on the newsgroup it gets the correct value, so clearly it's > possible to get the correct value. Does attachment 249378 [details] [diff] [review] in bug 298737 fixed dec 22 on trunk fix this problem? If not, is a potential patch difficult?

See dependency tree of meta Bug 71728. DUP of one of Bug 24592, Bug 34406, Bug 41457, Bug 79130, Bug 108650, Bug 202341. Sorry but I don't know which bug is correct one to DUP.

sorry for the spam. making bugzilla reflect reality as I'm not working on these bugs. filter on FOOBARCHEESE to remove these in bulk.

Filter on "Nobody_NScomTLD_20080620"

Joshua, see comment 11

(In reply to comment #10) > So, following the logic from Comment #9, I get to > nsNNTPNewsgroupList::GetRangeOfArtsToDownload in > mozilla/source/mailnews/news/src/nsNNTPNewsgroupList.cpp where the line of code > rv = args->SetArticleCount(*last - *first + 1); appears, and seems to agree with > the hypothesis. Yeah, that does not do what you think it does. That is the number of articles that will appear in the "hi, there are N new headers, how many do you want me to download?" dialog and has absolutely no bearing on the number of new messages in the newsgroup. That count may be wrong, but we have to download the headers first to see what the correct number may be, which would defeat the purpose of the dialog. As there is no other indication of possible failure causes other than vague references to things like expired messages (itself bug 79130), I am going to close this as INCOMPLETE.