Re: [Pan-users] "missing" articles

[Duncan]

On Tue 18 Mar 2003 04:54, Alberto BARSELLA posted as excerpted below:
> This is perfectly normal when the articles have not entirely propagated
> to a newsserver: usually it's enough to look one day later and everything
> is there.  Still, for this episode even after 2-3 days the situation was
> exactly the same.
>
> Now, if instead of opening the group and downloading new headers, I force a
> reload of all headers (using "more download options...").  The "missing"
> articles appear (and they appear marked as "read").
> Could this be a problem with article counting?  My knowledge of NNTP is
> low, and I don't know exactly how wraparound in article counting is handled
> in large-volume newsgroups.

This isn't likely to be wrap-around.  More likely, it's due to the way the 
server is handling it's articles, back-filling the numbering, which can mix 
up some readers, including PAN.

It works like this.  Each server has a message count for each individual 
newsgroup.  Say you log on today, and a particular group has message numbers 
from 10200 to 11350.  You read what you want, mark the rest read, and quit.  
Tommorrow you go back and check for new messages.  PAN looks and sees that 
the last message that was there yesterday was 11350, so it tells the server 
it wants any messages between that, and the new max count, say 11520.

So far so good.  However, take for example my ISP, Cox, which has three news 
servers.  To keep them syncronized, the numbers are assigned at a central 
location, so if one server goes down, we can switch to one of the others 
without having to d/l all headers again, since the numbers are all 
syncronized on all three servers.

Now, consider what happens when one server gets behind.  The main feed 
continues to get new articles in, and number them, but the troubled server 
only gets a few of those, and there are gaps in its numbering.  If the user 
now marks all messages as read, and the user agent (PAN, in this case) 
interpretes that as all messages up to (in the above example) 11350, but 
11237 and 10976 come in later, the user agent will wrongly think those are 
already read, and not display them the next day.

I might be wrong about this, as I haven't looked at the PAN innards to see, 
but I think PAN normally tracks numbering individually, so this problem 
shouldn't occur.  However, it's possible that when you mark an entire group 
read, rather than marking the individual articles read (select all, mark as 
read), it uses the highest article number seen to track that, and this may 
cause the issue you saw.  Thus, I'd suggest only marking the individual 
articles as read, probably using select all, mark as read, as I mentioned, 
rather than mark group as read.  Hopefully, that cures the problem.

Of course, occasionally, usually when the server itself has problems, it may 
reset its article numbering, and EVERYTHING would get screwed up.  The same 
may occur if you switch servers by simply changing the address of the server 
in PAN, and the servers aren't number-syncronized.  In these instances, 
resetting the group, or d/ling all headers, may be necessary, to get things 
back on track.  However, from your description, that shouldn't have been 
necessary, except that you'd apparently marked the entire group read, rather 
than individual articles, so that's what you ended up doing, necessary or 
not.

Of course, there may be other occasional instabilities or bugs, that cause 
one-off problems.  However, it shouldn't occur on a regular basis.  If it 
does, there's something else wrong.

-- 
Duncan
"They that can give up essential liberty to obtain a little
temporary safety, deserve neither liberty nor safety." --
Benjamin Franklin