Article 12345 unavailable: numbers not in sync
Martin Trautmann <[email protected]>
| Newsgroups | gmane.network.slrn.user |
|---|---|
| Message-ID | <[email protected]> |
Hi all, since there's much more activity within the slrn development again, I'd like to ask for another improvement. I do use a flawed news server setup here. slrn tells me many times: Article NUMBER unavailable This might indicate that the article is no longer kept on this server. But that's not true. When I change to ANOTHER usegroup and call this article via its message id, it's no problem to call this posting. When I try this within the newsgroup itself, it does not work, since this seems to fall back on the attempt to catch the number again. The reason is known: There's just one news server name (news.nexgo.de). However, the requests are spread to different servers, such as Xref: newsspool4.arcor-online.net GROUP:NUMBER These different servers are not in sync and use different numbers. Example: slrn tries to get de.comm.software.newsreader:103534 which is Message-ID: <[email protected]> Subject: Re: Weiterentwicklung von slrn References: [...] <[email protected]> This worked this time. Now I want to get the previous one, <[email protected]> Xref: newsspool4.arcor-online.net de.comp.hardware.cpu+mainboard.amd:109604 de.comm.software.newsreader:103533 ... and slrn might tell me: Article 103533 unavailable This happened since a different server would reply which would use the number such as 456777 for this posting instead. I don't know whether there's any RFD that would specify how different news servers behind one address should ensure that there message numbers always would be in sync. Concerning slrn, I'd welcome any improvement that would permit a fallback solution which would try another method once again if the call by message number would fail - probably not relying on xover headers only. It should be ensured that the list of read postings in .jnewsrc does use the proper number only. Thanks! Martin ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/