Re: [Pan-users] messages marked unread again

[Duncan]

David Chmelik posted on Sun, 13 Mar 2022 04:38:53 -0700 as excerpted:

> I have Slackware64 15.1+current pan 0.149.
>      Often (not always) when I restart pan and run it for a while I
>      find
> messages I marked as read days ago have been reset marked unread.
>      Even if I cleanly exit pan then start it some minutes later, it
> still happens.
>      I'm using news.eternal-september.org (ES,) news.aioe.org ,
>      gmane.org Another thing, when I got the groups from gmane (and a
>      few were on
> AIOE, but not ES, or vice-versa) I wish those were all automatically set
> in their profiles as part of GMANE, not my main (ES) profile... seems I
> have to do hundreds manually if I ever post...

First, please use block style paragraphs, skipping a line between 
paragraphs, no indent.  As you will likely know using pan for text 
messages, and I see you're using gmane so you presumably are, and also 
presumably already know that pan can be used for this list via gmane (as 
I'm doing), pan's wrapping code can be... quirky... with indents.  The 
above quote (which in another context I'd fix up manually) nicely 
demonstrates the problem.

The profiles thing next.  The above wasn't entirely clear to me (hundreds 
of individual posts or hundreds of groups, or ???) so this might seem a 
bit general, but hopefully it'll help.

To set the group default profile you edit the group preferences (which are 
stored in group-preferences.xml).  If it hasn't been set there the group 
posting profile default will be the overall default, which is the first 
profile in posting.xml, that normally being the first posting profile you 
happened to setup.  Regardless of which default is used for a group you 
can of course choose any posting profile when you post.

Should you find that the overall default doesn't make sense, there's a 
couple things you can do to change it.

1) Edit posting.xml manually, in a text editor, with pan closed.  Make a 
backup of the file first in case you screw up the editing, then move your 
desired profile to the top, being careful to select and move the entire 
profile, from the "<profile name=" line to the "</profile>" line, moving 
it just below the "<profiles>" line.  Save the file and open pan to test.  
If it didn't work as expected, you can quit pan again and move the backup 
you made back to the original location.

That should change the overall default, which will work if you have just 
one that you want to use most of the time and it just changed from one 
profile to a different one.  But it's not going to help much if you have 
multiple profiles that you want to use with many groups each.  For that 
you either need to set the profiles for all groups but the ones using the 
overall default, OR get a bit smarter in how you work with pan, which is 
where #2 comes in.

2) It's possible to setup multiple pan instances, each with their own 
entirely separate configuration, settings, cache, etc.

Pan honors the PAN_HOME environmental variable if set when it starts, 
looking there for all its settings, cache, etc.  Only if PAN_HOME isn't 
set will it use the built-in default, which on Linux at least I believe is 
~/.pan or ~/.pan2 .  (It was originally .pan with C-based pan, got changed 
to .pan2 with the C+ rewrite years ago, but may have been changed back or 
for all I know to something else since, I'm not actually sure as I've been 
setting PAN_HOME for so long.)

It's therefore possible to set PAN_HOME in a wrapper script before 
launching the pan binary, and by doing so, to setup multiple pan 
"instances" each with their own settings.  Here, I have three instances, 
text, text, binaries, but people can setup their instances otherwise if 
they want, say big-bins (for iso images, etc), bins, text, or music, 
images, text, or...

In your case you might setup es, gmane, aioe, for the server you want to 
be the default for the default posting profile.  Of course the other 
servers can still be setup too in each if desired, or not.  It's up to 
you.

What I actually did here was create a pan directory, with subdirs or 
symlinks to dirs on other partitions (I've found binaries in particular 
work best on their own partition so I can set a dedicated size that won't 
interfere with the rest of my setup, then set a HUGE cache of many gig), 
one per pan instance, with a globals subdir as well, containing files such 
as the hotkey settings files that I want the same across all instances.  
Then I can symlink the globals files from the individual instances.

If your computer has enough memory and other resources to do so and you've 
setup the instances correctly, you can even run more than one instance at 
once and they won't interfere with each other. =:^)

That should be enough for many, but if anyone needs it or is just curious, 
I can post my own wrapper script on request.


That leaves the read messages getting marked unread again problem.

>From my experience there's a several causes for this.  The most common 
you've already pretty much dealt with -- for performance reasons pan 
tracks a few minutes worth of read messages in memory before updating 
status on-disk and can thus forget them if it's shutdown incorrectly.  The 
setting for this is in preferences, misc., autosave articles.  Lowering 
that can help there, or alternatively, since pan saves state when you 
switch groups, get in the habit of switching to another group and back 
every so often to force pan to save the state.  (This was the recommended 
method before pan got the autosave articles timer, and I've had the habit 
long enough I still do it.)

There are other more obscure possible causes as well.

One you probably are NOT seeing is the 32-bit limit one, since presumably 
that slackware64 means you're 64-bit.  On a 32-bit machine using servers 
with long enough retention or who haven't reset their message-sequence 
numbers in long enough, the message-sequence numbers will end up greater 
than a 32-bit number can track.  I can't remember how pan handles that but 
it'd certainly cause problems.  Luckily you appear to be on 64-bit and 
presumably your pan is 64-bit also, so this cause shouldn't be anything 
you'll see.

That leaves at least one and possibly two others I've seen.  Unfortunately 
my memory is a bit foggy on the details as I used to see the problem 
mostly in binary groups and I've not done binaries regularly in years.  I 
actually tried writing up the detail but found it's blurry enough it 
wasn't making much sense so deleted it.

What I *can* suggest is increasing your cache size, and that you see 
whether it's cross-posting related and possibly occurs when you visit 
additional groups (beyond the first one you saw it in) to which the 
message was posted.

On cache size, pan's default (IIRC 5 or 10 MB) is mostly reasonable for 
text messages, tho it's possible it'll trigger occasional problems such as 
this.  And for binaries, for those doing direct-download, it's still 
somewhat reasonable, tho again, it could trigger occasional problems like 
this.  But for those like me trying to do binaries using a strategy of 
cache-what-looks-interesting first, then review when it's local and save 
or delete after review, a multi-gig cache size is *MUCH* more reasonable, 
preventing the "I downloaded it but pan erased it from cache before I 
could look at it" problem I had when I first tried pan, before I increased 
the cache size.  FWIW when I upgraded to 1 TB SSDs recently I setup a 50 
GiB dedicated binaries instance (see above multiple pan instances 
discussion) partition, which sould be 49+ GiB of cache, tho as I don't do 
binaries much any more it's mostly empty (which is OK, what I don't use is 
more wear-leveling space the SSD firmware can use).  My text instance has 
a dedicated 5 gig partition, still less than 2 gig used even though I have 
headers and many posts going back nearly two decades on some groups 
(gmane, plus some archived groups from my ISP back when it used to carry 
news).

Most of the time when I saw the read messages appearing unread problem, it 
was with cross-posted messages, when I visited an additional group (beyond 
the one I first saw it in) to which it had been posted.  As I said I'm 
blurry on the details now, but for sure, if the message was downloaded and 
is still in cache (as opposed to being marked read without downloading or 
to being already deleted from cache), if it get marked unread, it'll still 
show up as cached and thus be easy to see that you've already processed it 
and can mark it as read again from that.  (Click on the header of the 
column with the disk in it to sort by that, so all the cached ones are 
together and can be selected and marked read at once.)

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