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

[Duncan]

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/).

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.

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.

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).

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.)

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...)

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman