Re: [Pan-users] articles don't stay marked read

[David Chmelik]

On 10/16/23 1:07 AM, Duncan wrote:
> David Chmelik posted on Sat, 14 Oct 2023 05:03:28 -0000 (UTC) as
> excerpted:
>
> > I have Slackware64 15+current pan-0.154-x86_64-1 and lately had to
> > delete most out of ~/.pan2 because of other bugs.  All I still have from
> > there are server configuration and my ~/.newsrc files (linked to there)
> > and things are almost working okay lately (except for bugs mentioned
> > previously like no longer can move anything, maybe because of GTK).  Now
> > I have a new problem: if I read some groups then mark them all read, and
> > go to file-> quit and later restart, most groups (almost 1,500) are
> > marked unread, which is all articles I already read days/weeks/months
> > (maybe years) ago or ones I don't want to read right now.  This has
> > happened repeatedly; something isn't keeping them marked read anymore
> > before it exits.
> Your problem might be more serious than this, but...
>
> Try quick-switching to a different group (and back, if desired) and see if
> that locks in the status on the group you were in (switched /from/).
That's impractical: sometimes I mark several hundred groups read at once.

> Long ago, before pan got the autosave timers that in theory make this
> unnecessary (and through less-than-stable-system periods), I got in the
> habit of doing this periodically to force pan to save current status on the
> group I was working in.  That way, a crash (pan or system) would revert me
> to my last status-saving-switch, instead of forgetting the read-status of
> perhaps hundreds (text group I actually read) or thousands (binary group,
> could be tens of thousands in video groups) of messages.
>
> Of course with 1500 groups subscribed I don't suppose you're reading them
> all every session, but in theory, if you've not touched the group (and
> don't have any of the auto-fetch-headers and/or auto-mark-read options in
> preferences, behavior, groups, checked, if you do, try unchecking them and
> doing it manually and see if the problem persists), it shouldn't matter.
They were already un-checked/-ticked.

> The other read-tracking quirk I'm aware of regards cross-posts.  If headers
> are deleted from the first group(s) you read of the cross-posted groups
> before you visit one (or more) of the others, pan at least /used/ to (not
> sure if it still does) lose track of the fact that you'd already read those
> posts in the other group.  It could only track that fact as long as the
> headers were still there from the first group(s) of the cross-posts you
> visited.
It's at least 99% not cross-posts.  Just earlier today pan showed almost 
all (mostly unrelated) groups with new messages, even though many of 
them didn't have new messages.  It was often older messages that were 
showing up as unread with several newer ones still marked read.

> If none of that helps the bug is likely something to do with newsrc file
> handling (or the server-side parallel to it, see below) since that's where
> pan stores the read-message data.  Of course the actual bug could be in
> writing out the files (pan or its libs), the filesystem (kernel or
> hardware), reading them back in (pan or its libs), or even something
> corrupting memory (pan or its libs, the kernel, memory, CPU or powersupply
> hardware).
My PC has various hardware monitoring and didn't report any problems, 
and I've been using Linux kernel 6.1.n (SLTS).

> Or it could be server problems, particularly if it's a high-volume multi-
> machine load-balanced server.  In the past I've seen reports where such
> machines got out of sync for some reason, such that one or more bad
> machines were returning message sequence numbers that didn't match what the
> peer machines were doing.  Of course this tended to screw clients up
> sufficiently that people didn't stay connected to that machine for long, so
> its load was less than that of the others, which made the load-balancers
> all the more eager to send new connections to it!
>
> A way to check for this (also a symptom if you switch servers while using
> the same account and thus the same newsrc, or if the server resets its
> sequence numbers making it effectively a different server at the same
> address, as can happen with new hardware if the admins aren't careful to
> avoid the problem) is to examine the xref header sequence numbers,
> comparing them to the numbers in your newsrc for that group.  Accounting
> for posting volume of the group, if they're way off, that could explain
> things.  (Tho do note that a stale newsrc, say that pan is failing to
> update, a possibility discussed earlier, would have old, lower numbers, as
> well.)
I just use Eternal September (ES) and Gmane, and never saw this problem 
with them, but don't know which account you mean.  I'm looking for some 
other public servers now that AIOE closed (which had some more 
newsgroups ES doesn't).

> Of course the newsrc message sequence numbers could (in simplest concept)
> be lower or higher.  If they're lower, messages will appear unread as pan
> believes it didn't see them yet.  If they're higher, they'll all appear
> read as pan will think it already saw them.  (This is a bit simplistic
> since pan actually tracks ranges, allowing for gaps to be filled in due to
> held-but-already-numbered messages appearing later, etc.  But if already
> read messages appear for whatever reason with sequence numbers pan doesn't
> have in its newsrc ranges, or conversely, if new messages appear with
> numbers already listed in those ranges as read...)