Ron Johnson posted on Mon, 04 Apr 2011 21:19:55 -0500 as excerpted: > A twist: > > Downloading stuff at the moment. Did a Group Switch and then returned > to the original group. The articles *are* "flipping" from Bold to > Regular. > > Since this particular set of articles is only posted to a single group, > I wonder if the problem lies only with cross-posted articles.
Now that's a possibility, indeed. Pan does seem to get it correct in cache-first mode, at least if all groups are cached before processing. But it could screwup in download-and-save mode under certain conditions if there's a race between save in the one group and download in the other. Meanwhile, I have noticed an issue in cache-first mode, too, tho there it's one of operator error as much as pan problem. If the pattern is to cache for one group, then process, actually deleting posts that one is done with, then one goes to a second group to which the posts were cross- posted and gets new headers, the cross-posts show up there as unread, despite being read in the first group. *If* the posts are still in cache, pan can make the cross-post connection and marks them appropriately, because it has both the message-IDs which it uses to track the messages in cache, and all the group sequence numbers, which is what newsrc files (and thus pan, since it uses that standard) use to track read messages. But if the messages were actually deleted in the first group before entering the group to which they were cross-posted, pan at first only has the group sequence numbers and can't make the association until it actually downloads the messages back into cache. At which point they're "magically" marked read again, because it can then make the association between the message-ids and the group sequence numbers for both cross- posted groups once again. Which as I think about it, might actually be what you're seeing in the download-and-save scenario as well. Only in that case, the cache is presumably still set to the pan default 10 MB, meaning the actual posts will be deleted from cache pretty much as soon as all the segments per part complete and it can save them, so pretty much any visit to a group to which they're cross-posted will register them as not-yet-seen, thus requiring redownload. As pan redownloads, it sees that it already knows about the individual message, but by then it already has it, so no time saved. (Whether pan creates a second copy of the saved file, I don't know, as I don't use that mode.) If this is indeed correct, then there's a reasonably simple solution/work- around that definitely works in cache-first mode and will I believe work in download-and-save mode as well: Before actually scheduling any full messages for download, download headers (really, overviews, as it's not all headers, only those in the overview) for all related groups, either by downloading them for all groups, or by visiting all related groups and downloading them for that group, individually. Then schedule your downloads, and don't update headers again until the message downloads and saves (whether separately, cached and saved, or together) are fully completed. This should allow pan to mark downloaded messages as read for all subscribed cross-posted groups at once. Note that for this to work properly, you'll need to disable the automatically download headers at group entry, or at least, don't schedule downloads for any of those new headers, if you only visited the one group. Only schedule downloads when headers for all related groups are effectively in sync. The easiest way to ensure they're in sync is by using the download new headers for all groups function, which after completion should mean they're in sync, allowing you to schedule downloads without losing track of read messages due to the cross-posts. Try testing that for awhile and see if it cures the read/unread tracking. I think it will, at least as long as the servers themselves are keeping the groups in sync. (If the messages are seen in one group before another on the server, that's a server group-syncing problem, not pan's.) Meanwhile, for multi-server users who have the same groups on several servers, the same base problem could appear, only slightly worse, especially when a particular server doesn't carry all subscribed cross- posted groups, as variances in message propagation between servers is normal, and if a message hits a server only carrying part of the groups before it hits one carrying all of them, that message won't have a group sequence number for the groups that server doesn't carry, so again, the problem could appear. Only now there'd be no easy way for pan to sync the groups since it will have seen and likely dealt with the post on the one group the first server carried, before it saw the post on the second server and both/all groups (or the group the second server carried, if different, tho in that case it'd have to be indirect syncing between the two servers, but it could still happen). -- 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 http://lists.nongnu.org/mailman/listinfo/pan-users
