5.8.3 (CVS version) NNTP primary server stops updating unread number

5.8.3 (CVS version) NNTP primary server stops updating unread number

[Steinar Bang]

My problem, is that a normal
	g
in the *Group* buffer no longer updates the unread number on the NNTP
groups on the primary server (I only have this one NNTP server).
After the get command I see the text "nntp read: 15k" for a while in
the minibuffer, until it moves on to the secondary servers (nnml and
an nnimap server).

I can update the NNTP groups individually with
	M-g
but that is impractical in the long run.

Here's what I did:

Yesterday I decided to try nnslashdot.  When I did my first 
	A z
it listed a hug amount of zombie groups.
	S z
killed them, but also killed the nnslashdot groups.

Due to a bit of clumsyness on my part, a big number of the zombie
groups were subscribed, so I had to unsubscribe them, after I took an
	l
to show the normal list of groups.

Since I wanted to try out slashdot, without waiting for new groups to
appear, I stopped Gnus, and removed the nnslashdot groups from
gnus-killed-list, in ~/.newsrc.eld, and then restarted Gnus.

This seemed to work, except I occasionally get the hanging in 'Mark
set' that others have reported, so I have now removed it.

My guess is that somewhere in there, I messed up a setting in
~/.newsrc.eld.  But I have no clue about where to look.

Any hints and ideas welcome!


- Steinar

Re: 5.8.3 (CVS version) NNTP primary server stops updating unread number

[Steinar Bang]

>>>>> Steinar Bang <sb@metis.no>:

> My problem, is that a normal
> 	g
> in the *Group* buffer no longer updates the unread number on the NNTP
> groups on the primary server (I only have this one NNTP server).
> After the get command I see the text "nntp read: 15k" for a while in
> the minibuffer, until it moves on to the secondary servers (nnml and
> an nnimap server).

> I can update the NNTP groups individually with
> 	M-g
> but that is impractical in the long run.

Actually it updates the NNTP groups on 
	g
(ie. it increases the article count), but a
	M-g
shows even more articles.

To be fair I've only actually observed this in a single NNTP group.
However, this may be because it is the only NNTP group I read
regularily. 

> Here's what I did:

> Yesterday I decided to try nnslashdot.  When I did my first 
> 	A z
> it listed a hug amount of zombie groups.
> 	S z
> killed them, but also killed the nnslashdot groups.

> Due to a bit of clumsyness on my part, a big number of the zombie
> groups were subscribed, so I had to unsubscribe them, after I took an
> 	l
> to show the normal list of groups.

> Since I wanted to try out slashdot, without waiting for new groups to
> appear, I stopped Gnus, and removed the nnslashdot groups from
> gnus-killed-list, in ~/.newsrc.eld, and then restarted Gnus.

> This seemed to work, except I occasionally get the hanging in 'Mark
> set' that others have reported, so I have now removed it.

> My guess is that somewhere in there, I messed up a setting in
> ~/.newsrc.eld.  But I have no clue about where to look.

> Any hints and ideas welcome!

Re: 5.8.3 (CVS version) NNTP primary server stops updating unread number

[Steinar Bang]

>>>>> Steinar Bang <sb@metis.no>:

>>>>> Steinar Bang <sb@metis.no>:
>> My problem, is that a normal
>> g
>> in the *Group* buffer no longer updates the unread number on the NNTP
>> groups on the primary server (I only have this one NNTP server).
>> After the get command I see the text "nntp read: 15k" for a while in
>> the minibuffer, until it moves on to the secondary servers (nnml and
>> an nnimap server).

>> I can update the NNTP groups individually with
>> M-g
>> but that is impractical in the long run.

> Actually it updates the NNTP groups on 
> 	g
> (ie. it increases the article count), but a
> 	M-g
> shows even more articles.

> To be fair I've only actually observed this in a single NNTP group.

This rang a bell, and looking in the ~/.newsrc.eld file, I have found
that I have both an "nntp+news.eunet.no:no.alt.motorsykler", and a
"no.alt.motorsykler".

Now the questions are:
 1. how did the first group appear?
 2. can I merge them, or do I need to delete them both, and
    resubscribe?

Re: 5.8.3 (CVS version) NNTP primary server stops updating unread number

[Steinar Bang]

>>>>> Steinar Bang <sb@metis.no>:

>>>>> Steinar Bang <sb@metis.no>:
>>>>> Steinar Bang <sb@metis.no>:
>>> My problem, is that a normal
>>> 	g
>>> in the *Group* buffer no longer updates the unread number on the NNTP
>>> groups on the primary server (I only have this one NNTP server).
>>> After the get command I see the text "nntp read: 15k" for a while in
>>> the minibuffer, until it moves on to the secondary servers (nnml and
>>> an nnimap server).

>>> I can update the NNTP groups individually with
>>> 	M-g
>>> but that is impractical in the long run.

>> Actually it updates the NNTP groups on 
>> 	g
>> (ie. it increases the article count), but a
>> 	M-g
>> shows even more articles.

>> To be fair I've only actually observed this in a single NNTP group.

> This rang a bell, and looking in the ~/.newsrc.eld file, I have found
> that I have both an "nntp+news.eunet.no:no.alt.motorsykler", and a
> "no.alt.motorsykler".

> Now the questions are:
>  1. how did the first group appear?
>  2. can I merge them, or do I need to delete them both, and
>     resubscribe?

The nntp+news.eunet.no group was on level 6 and has probably been
there for ages, through many versions of Gnus and pgnus and now Gnus
again. 

Why it suddenly started to make problems is anyone's guess.

In any case I killed the nntp+news.eunet.no:no.alt.motorsykler group,
using 
	S k
saved ~/.newsrc.eld, and this seems to have cured the problem.

Re: 5.8.3 (CVS version) NNTP primary server stops updating unread number

[Steinar Bang]

>>>>> Steinar Bang <sb@metis.no>:

>>>>> Steinar Bang <sb@metis.no>:
>>>>> Steinar Bang <sb@metis.no>:
>>>>> Steinar Bang <sb@metis.no>:
>>>> My problem, is that a normal
>>>> g
>>>> in the *Group* buffer no longer updates the unread number on the NNTP
>>>> groups on the primary server (I only have this one NNTP server).
>>>> After the get command I see the text "nntp read: 15k" for a while in
>>>> the minibuffer, until it moves on to the secondary servers (nnml and
>>>> an nnimap server).

>>>> I can update the NNTP groups individually with
>>>> M-g
>>>> but that is impractical in the long run.

>>> Actually it updates the NNTP groups on 
>>> g
>>> (ie. it increases the article count), but a
>>> M-g
>>> shows even more articles.

>>> To be fair I've only actually observed this in a single NNTP group.

>> This rang a bell, and looking in the ~/.newsrc.eld file, I have found
>> that I have both an "nntp+news.eunet.no:no.alt.motorsykler", and a
>> "no.alt.motorsykler".

>> Now the questions are:
>> 1. how did the first group appear?
>> 2. can I merge them, or do I need to delete them both, and
>> resubscribe?

> The nntp+news.eunet.no group was on level 6 and has probably been
> there for ages, through many versions of Gnus and pgnus and now Gnus
> again. 

> Why it suddenly started to make problems is anyone's guess.

> In any case I killed the nntp+news.eunet.no:no.alt.motorsykler group,
> using 
> 	S k
> saved ~/.newsrc.eld, and this seems to have cured the problem.

Nope.  The problem persists.  All groups seems to update correctly
when I start Gnus, but not all of them seems to updata correctly on
subsequent 
	g
commands in the *Group* buffer.  The only group I've seen this
behaviour in, is still no.alt.motorsykler.