On 9/9/23 12:03 AM, Duncan wrote:
dchmelik-Re5JQEeQqe8AvxtiuMwx3w posted on Fri, 8 Sep 2023 00:31:29 -0700
as excerpted:

On 9/7/23 2:26 AM, Duncan wrote:
dchmelik-Re5JQEeQqe8AvxtiuMwx3w posted on Thu, 7 Sep 2023 00:20:07
-0700 as excerpted:

If I select a high-activity group I haven't read before (such as
gmane.linux.kernel which I guess is the mailing list and has hundreds
thousands posts) pan soon stops working/responding.  I can no longer
select any other group, nor any menu item, and if I cover or minimize
pan and return later, it no longer even redraws its screen.  Today
this has gone one for about six hours, which just to show one screen
of posts, it shouldn't take this long!  I don't know why it'd have to
prepare to show all posts from years ago because I probably won't look
that far back.  Pan even stops responding like this if I mark that
I've read all articles in the high-activity group and come back later,
perhaps just to see the top page of articles.
Please verify the following preference is UNCHECKED:

Preferences > Behavior > Groups > Get new headers when entering group

(I keep Get new headers in subscribed groups on startup unchecked as
well,
for similar reasons, but if you're careful not to subscribe to groups
that are too high volume that should be less of an issue, because
unlike when you first enter a group, presumably pan has a memory of
where you were in all your subscribed groups.)
I set both those preferences and tried to read gmane.linux.kernel
again... same happened.  This time I waited several hours, came back
several times, waited overnight and checked a few more times, and
finally waited 30 hours before I reboot so pan got killed.  I think pan
getting killed in the past messed up how it saved some files and was
causing the crashing I was having for years.

Then, when grabbing your first headers, us the get headers ... dialog
instead of getting new/all headers, and get the last N-days-worth or N-
hundred headers, thus restricting that initial header download.
For purposes of comparison, I just tried that group (gmane.linux.kernel)
here.  I don't think I had visited it before as it popped up the get-
headers dialog on its own when I entered the group.

The get-headers dialog defaulted to 60 days worth of headers.  I said OK
and let it fetch.  It now says it has 16,205 unread (I didn't click on any
so they all remained unread).  FWIW 8k/mo messages isn't actually as bad as
I had suspected it might be based on the comparisons I've seen to reading
LTML being like trying to drink from the end of an active firehose...
certainly compared to some of the busiest binary video groups, tho there
1000-to-1 or more multipliers due to the binaries aren't uncommon so it's
different.

Took a few seconds I guess.  FWIW, ~ decade-old 6-thread amd fx6100, 16 gig
RAM, long upgraded to SSDs tho, with my pan text-mode instance on a
dedicated 5-gig capacity filesystem  with 3.6 gig free (btrfs raid1 mode
data/metadata both, on a pair of 5-gig partitions, one on each of a pair of
ssds), inet connectivity throttled by an old 100 Mbit ethernet WAN router.

So agreed, something's definitely screwed up with your pan.

Next thing to try...

I'm assuming you've already done an fsck (or equivalent filesystem check on
MS) and it's clean, and you've run smartctl -AH or the like to check disk/
ssd health, also clean.
I think my OS does this on every boot and it was clean after I got up... I think I'd get GUI notifications if the SSD or HDD was damaged.

In your pan dir (on *ix, ~/.pan2 unless you've set $PAN_HOME (as I have),
IIRC):

First try a quick fix... if it works.  Maybe the tasks.nzb file is
corrupt.  Assuming you don't have any uncompleted downloads or the like
that you'll miss, with pan closed, just delete that file.  Pan will
recreate a fresh one when it restarts.

Next, check groups/gmane.linux.kernel.  If it exists it should be a text
file; FWIW ~6.1 MB after the above load, here.  You should be able to just
delete it if desired since you haven't gotten the group to load anyway, but
you may want to load it in a text editor to see if there's any obvious
corruption (switches to binary part way through or something) first.

We'll check and edit the gmane.linux.kernel lines in the newsgroups.xov and
newsrc files too.  For these files you likely want to make backups before
editing since if the files get screwed up it can mess up pan's tracking for
all the other groups too.

Open your newsgroups.xov file in a text editor.  Does it have a line for
gmane.linux.kernel?  FWIW, here's mine (again, after the above header load,
there's a comment line at the top of the file with the format)

gmane.linux.kernel 16205 16205 1:4908585

Try just deleting the line (and saving, with pan closed of course) if it
exists.

And finally, the newsrc file(s), of which you'll have one per server, with
the newsrc:server mapping found in servers.xml.  This tracks read messages
based on server message-sequence numbers.  Note that due to cross-posting
pan may have some messages listed as already read based on them being read
in other groups even if you've never (successfully) opened the listed
group.

FWIW, here's the entry I have for that group in my gmane newsrc (single
line in the file, it'll wrap at the single space after the exclamation,
here):

gmane.linux.kernel!
0-7380,50432,50440,50445,50503,159981,198273,217961,222263-222265,228815,260045,321972,322043,322163,624724,624752,625133,625286,625787,625820,625

Again, try just deleting the line (and saving) if it exists.
I did all above except deleting it from newsrc, because there weren't numbers after it anyway (not even wrapped to another line) and I didn't want to have to delete & re-add it... seemed it was just a normal entry that wasn't affecting the problem.  After this, I got the last week's headers, which are 2.3MB, and was able to take a look.  The groups file was 1.8GB and apparently hadn't even finished (I don't know how large it would've been if I got it from the beginning of Gmane which I don't have much reason to right now).

With any luck that should unscrew whatever's screwed up for that group, and
you can then successfully do what I did as a quick check for LKML, above.
Thanks! :)


_______________________________________________
Pan-users mailing list
Pan-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/pan-users

Reply via email to