pan-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: David Chmelik
Subject: Re: [Pan-users] articles don't stay marked read
Date: Mon, 16 Oct 2023 18:52:26 -0700
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.9.1

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]