What to do when Article numbers are unreliable?

What to do when Article numbers are unreliable?

[David Kastrup]

Hi,

with my current news provider, it appears like I get one of a bunch of
news servers on each connection, and the relation between article
numbers and articles is not kept.  That means that whenever I type ^
in order to go up in a thread which I have read before, I get an
"article has been cancelled or expired" message.  A nuisance.  The
same happens when trying to access old articles.

Is there a possibility to forget the "article id"-"article number"
correlation whenever the connection to the server closes?

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: What to do when Article numbers are unreliable?

[Frank Schmitt]

David Kastrup <dak@gnu.org> writes:

> with my current news provider, it appears like I get one of a bunch of
> news servers on each connection, and the relation between article
> numbers and articles is not kept.  That means that whenever I type ^
> in order to go up in a thread which I have read before, I get an
> "article has been cancelled or expired" message.  A nuisance.  The
> same happens when trying to access old articles.
>
> Is there a possibility to forget the "article id"-"article number"
> correlation whenever the connection to the server closes?

I don't think so. Gnus uses article numbers for remembering which
articles you've read, not Message-IDs.

-- 
Did you ever realize how much text fits in eighty columns? If you now consider
that a signature usually consists of up to four lines, this gives you enough
space to spread a tremendous amount of information with your messages. So seize
this opportunity and don't waste your signature with bullshit nobody will read.

Re: What to do when Article numbers are unreliable?

[Ivan Boldyrev]

On 9568 day of my life David Kastrup wrote:
> with my current news provider, it appears like I get one of a bunch of
> news servers on each connection, and the relation between article
> numbers and articles is not kept.

Use leafnode as proxy server or (better) change provider because
provider's admins are idiots, and new problems are just waiting...

-- 
Ivan Boldyrev

                       Perl is a language where 2 x 2 is not equal to 4.

Re: What to do when Article numbers are unreliable?

[David Kastrup]

Ivan Boldyrev <boldyrev+nospam@cgitftp.uiggm.nsc.ru> writes:

> On 9568 day of my life David Kastrup wrote:
>> with my current news provider, it appears like I get one of a bunch of
>> news servers on each connection, and the relation between article
>> numbers and articles is not kept.
>
> Use leafnode as proxy server or (better) change provider because
> provider's admins are idiots, and new problems are just waiting...

Probably my analysis was backwards: updating news seems to work pretty
ok (which articles are read or not), but it is pretty impossible to
get a message using its article Id (like with ^ ) unless it has
already been fetched in this session.

So maybe access by article Id is what is borked.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: What to do when Article numbers are unreliable?

[David Kastrup]

David Kastrup <dak@gnu.org> writes:

> Ivan Boldyrev <boldyrev+nospam@cgitftp.uiggm.nsc.ru> writes:
>
>> On 9568 day of my life David Kastrup wrote:
>>> with my current news provider, it appears like I get one of a bunch of
>>> news servers on each connection, and the relation between article
>>> numbers and articles is not kept.
>>
>> Use leafnode as proxy server or (better) change provider because
>> provider's admins are idiots, and new problems are just waiting...
>
> Probably my analysis was backwards: updating news seems to work pretty
> ok (which articles are read or not), but it is pretty impossible to
> get a message using its article Id (like with ^ ) unless it has
> already been fetched in this session.
>
> So maybe access by article Id is what is borked.

No, can't be quite that.  When I press ^, the appropriate summary line
with subject, author, number of lines actually appears, but it flashes
yellow, gets marked with "G" and I get an "article was canceled or
expired" message.

Can anybody put a finger on what combination of circumstances would
trigger such a behavior?  I am somewhat at a loss of where to look for
the problem, and what exactly to report the provider of news.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: What to do when Article numbers are unreliable?

[Frank Schmitt]

David Kastrup <dak@gnu.org> writes:

> Can anybody put a finger on what combination of circumstances would
> trigger such a behavior?  I am somewhat at a loss of where to look for
> the problem, and what exactly to report the provider of news.

Maybe some old information from your old provider are still laying
around somewhere (~/News or something alike)? I'd try to start Gnus
under a different user to check if the problem persists.

-- 
Did you ever realize how much text fits in eighty columns? If you now consider
that a signature usually consists of up to four lines, this gives you enough
space to spread a tremendous amount of information with your messages. So seize
this opportunity and don't waste your signature with bullshit nobody will read.

"expired or been canceled" after `gnus-summary-refer-parent-article' (was: What to do when Article numbers are unreliable?)

[Reiner Steib]

On Fri, Aug 18 2006, David Kastrup wrote:

> No, can't be quite that.  When I press ^, the appropriate summary line
> with subject, author, number of lines actually appears, but it flashes
> yellow, gets marked with "G" and I get an "article was canceled or
> expired" message.

What is the value of `gnus-refer-article-method'[1]?

> Can anybody put a finger on what combination of circumstances would
> trigger such a behavior?  

Wild guess: the HEAD command (see below) is successful, but the
ARTICLE command fails for some reason.

> I am somewhat at a loss of where to look for the problem, and what
> exactly to report the provider of news.

Set `nntp-record-commands' to t and look at the commands sent to the
news server(s) in the `*nntp-log*' buffer.  With my setting[1], I
get...

,----[ *nntp-log* ]
| 20060818T104525.795 localhost HEAD <m3y7u7eys0.fsf@foo.bar.invalid>
| 20060818T104533.607 news.belwue.de MODE READER
| 20060818T104533.638 news.belwue.de GROUP gmane.emacs.gnus.user
| 20060818T104533.658 news.belwue.de HEAD <m3y7u7eys0.fsf@foo.bar.invalid>
| 20060818T104533.852 news.gmane.org MODE READER
| 20060818T104533.897 news.gmane.org GROUP gmane.emacs.gnus.user
| 20060818T104533.933 news.gmane.org HEAD <m3y7u7eys0.fsf@foo.bar.invalid>
| 20060818T104534.099 news.gmane.org ARTICLE <m3y7u7eys0.fsf@foo.bar.invalid>
`----

The output of the last nntp command is in the ` *nntpd*' buffer.

Bye, Reiner.

[1]
,----[ <f1> v gnus-refer-article-method RET ]
| gnus-refer-article-method is a variable defined in `gnus'.
| Its value is shown below.
| 
| Documentation:
| Preferred method for fetching an article by Message-ID.
| [...]
|
| Value:
| (current
|  (nntp "localhost")
|  (nnml "personal")
|  (nnml "news")
|  (nnml "archive")
|  (nntp "news.belwue.de")
|  (nntp "news.gmane.org")
|  (nntp "news.gnus.org")
|  (nnweb "google"
| 	(nnweb-type google)))
`----
-- 
       ,,,
      (o o)
---ooO-(_)-Ooo---  |  PGP key available  |  http://rsteib.home.pages.de/