Re: Unacceptably slow entry into large nntp group

[Kevin Greiner <kgreiner@xpediantsolutions.com>]

Graham Murray <graham@gmurray.org.uk> writes:

> gnus (latest CVS) has become unacceptably slow entering an nntp group
> (local server) which has a lot (80000) unread messages. Knowing that
> generating the summary for all the unread messages would be slow, I
> selected to only read the latest 100. I have used this technique over
> the last few weeks to catch up with other groups (but I had also
> fallen behind with keeping gnus up-to-date). I do not know how long
> it would have taken to complete as i aborted (C-g) after 1 hour and
> 20mins of the messages "Finding Sort Keys" and "Reordering Buffer"
> alternating and emacs using 95% CPU. 

The problem is that your server sent article numbers that can't be
read into an emacs int (they overflow).  The bad article numbers are
now part of the ".overview" file that the agent maintains for each
group.

To fix, try: 
1) Put point in the group buffer on the group that can not be opened.
2) Do M-x gnus-agent-regenerate-group

If that doesn't fix it, you can also search around for the ".overview"
file then edit it manually.  The article numbers are the first field
in each line.  For the file to be correct, the article numbers should
be unique, small enough to read by emacs {you can use M-: (read
(current-buffer)) to test individual numbers}, and in ascending order.

BTW, the infinite loop between "finding keys" and "reordering" was
reported yesterday.  I should have a fix shortly.

Kevin