[Pan-users] Re: Bug in Headers pane?

[Duncan]

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