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