Closed Bug 365819 Opened 18 years ago Closed 16 years ago

Newsgroup unread count not cleared when no new postings

Categories

(SeaMonkey :: MailNews: Message Display, defect)

1.8 Branch
defect
Not set
minor

Tracking

(Not tracked)

RESOLVED DUPLICATE of bug 79130

People

(Reporter: jimoe, Unassigned)

Details

User-Agent:       Mozilla/5.0 (OS/2; U; Warp 4.5; en-US; rv:1.8.1.1) Gecko/20061223 SeaMonkey/1.1 Mnenhy/0.7.4.0
Build Identifier: Mozilla/5.0 (OS/2; U; Warp 4.5; en-US; rv:1.8.1.1) Gecko/20061223 SeaMonkey/1.1 Mnenhy/0.7.4.0

The unread count for a newsgroup is left unchanged of there are no new postings. It often happens that the actual unread count is 0. But the displayed unread count is left unchanged even when "Mark Newsgroup Read" is selected.

The key part to this is that there are no new postings on the ng server.

<news.ecomstation.nl>

Reproducible: Sometimes

Steps to Reproduce:
I suspect this is partly a problem with newsgroup servers.

I have no control over this behavior. When SM and the ng server disagree about unread counts, SM sometimes does not change its displayed account to 0 when there are no new postings.


Expected Results:  
If there are no unread messages for a newsgroup, SM should show no unread count.
Searching for "unread count" in the relevant components 
https://bugzilla.mozilla.org/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=unread+count&classification=Client+Software&classification=Components&product=Core&product=Mozilla+Application+Suite&product=Thunderbird&component=Mail+Window+Front+End&component=MailNews%3A+Backend&component=MailNews%3A+Main+Mail+Window&component=MailNews%3A+Networking&component=Networking%3A+News&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED
gives me 28 other bugs that are similar to this one, not even counting duplicates. It is unlikely that this is a new bug, but I don't have a clue which of those bugs to choose as a dupe... Also unlikely to be platform specific;  reported as a problem with a 1.8 branch build.
OS: OS/2 → All
Hardware: PC → All
Version: unspecified → 1.8 Branch
Hmm. I only found 17. And none of them were a duplicate of this problem report.
Did you search yourself or click the link in comment 1? I still get 29 in total for that search. And I was referring to bugs marked as duplicate but not (necessarily) of this bug...
I tried a new search using "unread count", with quotes.

I looked at all of the entries from the link in comment #1. None of them match this issue.
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.
I had this behavior before, but as i remember it's gone in 1.1 branch. Didn't have problems several months, seems fixed somewhere.
Status: UNCONFIRMED → RESOLVED
Closed: 16 years ago
Resolution: --- → WORKSFORME
I can verify that it is not.
Mozilla/5.0 (OS/2; U; Warp 4.5; en-US; rv:1.8.1.12) Gecko/20080210

None of the suggested possible reports are a duplication of this one. I looked at them all.

A slight variation on this is that until new postings arrive in a newsgroup the unread count always reverts to whatever number SM has decided should be there. I have seen 1, 2, 125, 333, and 500. "Get messages for account" and "Mark newsgroup as read" actions both clear the unread count... until the server is queried again.

A suggested hack of editing the newsgroup's RC file to remove multiple message ID ranges did not affect this particular issue.
Jim, can you reopen this bug if you belive it's no resolved ? I don't have permision to do so. Also can you test latest seamonkey trunk builds ? As i more than 6 month use primarily trunk, and 1.1 branch only for testing, i can miss something.
Also Jim, if you can reproduce it on thunderbird, please change Product to Core. This bug shouldn't be specific to Seamonkey, because it shares same mailnews part with Thunderbird.
Status: RESOLVED → UNCONFIRMED
Resolution: WORKSFORME → ---
Status: UNCONFIRMED → RESOLVED
Closed: 16 years ago16 years ago
Resolution: --- → DUPLICATE
Jim, are you sure these are neither expired, nor canceled messages that confuse your application?
Yes. There is one newsgroup (comp.os.os2.announce) whose activity is so low that there are no postings remaining, yet the count always reverts to 125.
Hm, I've subscribed to news.ecomstation.nl, but it only gives me access to ecomstation.* newsgroups.

Re: comment #0: the reason for unread message appearing when there are none is more interesting than the reason why their count isn't updated when there are no new messages. It STILL seams a very probable dupe of bug #79130. Say your current unread count is X, and there are no new messages. Then, I think, it's very much likely that even if there were Y new postings on that group, the unread count would be that X+Y, not just Y. So, those "phantom" messages, that are count as unread, could have been canceled a long ago. Or perhaps it was some sort of spam that slipped to the newsgroups, and admins have later canceled.

Re: comment #7: I suspect you haven't used the hack properly.

I guess a line like this:
baen.buships: 1-28405,28420,28422,28423,28428,28430,28432-28434,28437

should be changed to this:
baen.buships: 1-28437

note that you don't just delete everything after the first comma, but instead use the first and the last number in line (and separate them with a dash) to tell the application that ALL messages are read. And of course make sure the application isn't running at the time you are doing that. :)
Comment #0: 

Comment #7: Yes, I did hack the (ng).rc file as described. I included the last index (?) as the endpoint, not the first before the comma. I have also tried arbitrarily changing the endpoint value by +/-1 and +/-10. It did not make any difference.

The particular ng I mentioned previously has always shown

comp.os.os2.announce: 1-4449

so there was no need or opportunity to hack it.
No longer blocks: messagecount
You need to log in before you can comment on or make changes to this bug.