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