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. 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. 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. -- 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 _______________________________________________ Pan-users mailing list Pan-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/pan-users
