Closed Bug 366514 Opened 18 years ago Closed 16 years ago

nntp, insists on 35984 new messages in a newsgroup, every time

Categories

(MailNews Core :: Networking: NNTP, defect)

x86
Windows XP
defect
Not set
major

Tracking

(Not tracked)

RESOLVED INCOMPLETE

People

(Reporter: alfps, Unassigned)

Details

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.8) Gecko/20061025 Firefox/1.5.0.8
Build Identifier: version 1.5.0.9 (20061207)

I've used Thunderbird as a newsreader (NNTP) for a long time.  Just now it started reporting 35984 new messages in [comp.lang.c++].  Downloading the message headers doesn't help: the "new" headers are downloaded and displayed, then next time I click on [comp.lang.c++], there the same message about 35984 new messages pops up.  Marking the group read doesn't help (and doesn't actually do anything).  Presumably what's wrong is simply a "last message" id somewhere corrupted, but possibly this requires having used Thunderbird as newsreader for a long time (overflowing that id in some way).  Extra info: I haven't changed NNTP-server, it's [news.individual.net] and I doubt they change the article numbering (and even if they did, Thunderbird should be able to deal with it).


Reproducible: Always

Steps to Reproduce:
1. Use Thunderbird as newsreader for a long time (at least several months).
2. When TB starts reporting a large number of new articles in a newsgroup N:
3. Download all articles.
4. Click on another newsgroup.
5. Click on newsgroup N again.
6 The same message about large number of new articles appears.

Actual Results:  
http://home.no.net/alfps/_misc/ugh.png

Expected Results:  
Reporting only actual new articles in the newsgroup, if any.
When updating the newsgroup folders (clicking [News.Individual.Net] server folder and then "Get Mail") the [comp.lang.c++] folder item in the folder list seems to correctly show the number of actual new articles, e.g. 43.  But clicking on that folder to show contents produces the incorrect message about 35984 new articles.

I.e., it seems that internally one part of Thunderbird handles this correctly (folder list), while another part is stuck in a reality dysfunction (folder content display).

I.e., it's not just some limit exceeded, wrong article numbering or such: there is direct inconsistency in the presented information.
WORKAROUND.

I fixed the behavior by (1) downloading the 500 last alleged "new" article headers, and (2) choosing [View -> Threads -> Expand all threads].

This removed the underlining marking threads as containing unread articles (marking the folder as read did not work).

Bug + other bug = workaround. ;-)  Well, I don't know whether this procedure will work in the future, if the problem remanifests itself.  But at least I can now again use the [comp.lang.c++] newsgroup.
It's back with a vengeance: now 9000-and-some unread articles reported (every time) in [comp.lang.c++.moderated], and the "expand all threads" workaround doesn't help.
What's the content of the comp.lang.c++.moderated newsrc? The fixes described in several other bugs (most notably bug 71728 and bug 79130, of which this probably a dupe) should work.

If no response within 3 weeks I will RESO INCO.
Assignee: mscott → nobody
Blocks: messagecount
Component: General → Networking: News
Product: Thunderbird → Core
QA Contact: general → networking.news
Whiteboard: closeme 2008-07-03
Looks to me like a dupe of bug 79130, which has a workaround in bug 294754 comment #3 (another dupe).
Most likely, this is a dupe of bug 79130. However, there is not quite sufficient information to tell (there ARE other news count bugs other than 79130). With that in mind, I am RESO INCO.
No longer blocks: messagecount
Status: UNCONFIRMED → RESOLVED
Closed: 16 years ago
Resolution: --- → INCOMPLETE
Whiteboard: closeme 2008-07-03
Product: Core → MailNews Core
You need to log in before you can comment on or make changes to this bug.