Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3a) Gecko/20021122 I am observing this bug for a very long time, but never worked it out. Now I did investigate and found the following: When you have a newsgroup where the last message (as given by the group command) is missing (nothing returned by xover), there will alway be an unread count of at least one. If you mark the group as read this goes down to zero, but the next update brings it back. Here are the details. Let me first show you the situation as observed with telnet: [3.14@pi ~]$ telnet news.univie.ac.at 119 Trying 131.130.1.118... Connected to news.univie.ac.at. Escape character is '^]'. 200 news.univie.ac.at NNRP Service Ready - news-adm@news.univie.ac.at (posting ok). MODE READER 200 news.univie.ac.at NNRP Service Ready - news-adm@news.univie.ac.at (posting ok). GROUP de.comm.provider.usenet 211 666 11167 11832 de.comm.provider.usenet xover 11832 224 data follows . quit 205 Transferred 236 bytes in 0 articles, 1 group. Disconnecting. Connection closed by foreign host. So you see that the group contains messages 11167-11832, but the last does not exist anymore (probably cancelled). Now let's see what Mozilla does (from nntp log, I reduce to the interesting part): First I open (expand) this news server: 1024[80896e0]: (8dff020) Receiving: 200 news.univie.ac.at NNRP Service Ready - news-adm@news.univie.ac.at (posting ok). 1024[80896e0]: (8dff020) Next state: NNTP_LOGIN_RESPONSE 1024[80896e0]: (8dff020) Next state: NNTP_SEND_MODE_READER 1024[80896e0]: (8dff020) Sending: MODE READER 1024[80896e0]: (8dff020) Next state: NNTP_RESPONSE 1024[80896e0]: (8dff020) Receiving: 200 news.univie.ac.at NNRP Service Ready - news-adm@news.univie.ac.at (posting ok). 1024[80896e0]: (8dff020) Next state: NNTP_SEND_MODE_READER_RESPONSE 1024[80896e0]: (8dff020) Next state: SEND_FIRST_NNTP_COMMAND 1024[80896e0]: (8dff020) Next state: NEWS_DISPLAY_NEWS_RC [various groups] 1024[80896e0]: (8dff020) Sending: GROUP de.comm.provider.usenet 1024[80896e0]: (8dff020) Next state: NNTP_RESPONSE 1024[80896e0]: (8dff020) Receiving: 211 666 11167 11832 de.comm.provider.usenet 1024[80896e0]: (8dff020) Next state: NEWS_DISPLAY_NEWS_RC_RESPONSE 1024[80896e0]: (8dff020) Next state: NEWS_DISPLAY_NEWS_RC 1024[80896e0]: (8dff020) Next state: NEWS_DONE 1024[80896e0]: (8dff020) Next state: NEWS_FREE OK, now I click on the group de.comm.provider.usenet, at this time one new message is displayed: 1024[80896e0]: (8dff020) ParseURL 1024[80896e0]: (8dff020) fullPath = /de.comm.provider.usenet 1024[80896e0]: (8dff020) m_messageID = (null) 1024[80896e0]: (8dff020) group = de.comm.provider.usenet 1024[80896e0]: (8dff020) commandSpecificData = (null) 1024[80896e0]: (8dff020) m_key = -1 1024[80896e0]: (8dff020) Next state: SEND_FIRST_NNTP_COMMAND 1024[80896e0]: (8dff020) Sending: GROUP de.comm.provider.usenet 1024[80896e0]: (8dff020) Next state: NNTP_RESPONSE 1024[80896e0]: (8dff020) Receiving: 211 666 11167 11832 de.comm.provider.usenet 1024[80896e0]: (8dff020) Next state: SEND_FIRST_NNTP_COMMAND_RESPONSE 1024[80896e0]: (8dff020) Next state: SETUP_NEWS_STREAM 1024[80896e0]: (8dff020) Next state: NNTP_XOVER_BEGIN 1024[80896e0]: (8dff020) SetCurrentGroup to de.comm.provider.usenet 1024[80896e0]: (8dff020) Next state: NNTP_FIGURE_NEXT_CHUNK 1024[80896e0]: (8dff020) Next state: NEWS_PROCESS_XOVER 1024[80896e0]: (8dff020) Next state: NEWS_DONE 1024[80896e0]: (8dff020) Next state: NEWS_FREE Too bad the log file does not show the actual dialog, but it must have sent XOVER to the server and received nothign for the last message. Anyhow, the unread count is still at one, but no message is found as unread. So I press mark group read. Then I collapse and expand the server again. The log looks exactly like the the first time above. Here is what newsrc-news.univie.ac.at has to say about the group in question (after closing Mozilla, just to be sure it is finally written): de.comm.provider.usenet: 1-11831 As you can see, the last number is too small. It should have been updated on XOVER or at the latest on mark group read. There is nothing I can see to repair the unread count for the user. The only solution is to manually repair the .newsrc. Hence marking major. pi

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"

Boris, do you still see this problem in TB 2.0.0.* or recent Trunk TB builds? If no response in 3 weeks, I will close this bug as INCO.

I no longer use SeaMonkey for news. But I have given clear explanation how you can reproduce the exact situation which causes the problem. So you can test it. pi

It's difficult to actually test problems with expired messages. In lieu of any better information, duping to 79130.

It does not depend on a particular message, but on a specific situation as described. Having said that the dupe sound right. pi