[Pan-users] Re: "freezes" in recent releases

[Duncan]

Phil <address@hidden> posted
address@hidden, excerpted
below, on  Thu, 02 Nov 2006 23:10:40 -0600:

> I have a problem on the past number of versions (including the latest
> beta) where large binaries seem to get stuck at around 98-99% and just
> hang there, while the other connections continue on to the other files
> in the que.  Often I can't even delete these "stuck" downloads from
> the task list (it won't let me) and I have to wait for them to
> eventually time out (sometimes hours later).  Even if I restart Pan,
> the stuck downloads are still there.

That's likely due to corrupt downloads that don't match the crc32 yEnc
includes with the file.  I don't believe those saving attachments directly
have a lot they can do about it (and it's a tough problem to solve so is
likely post-1.0 in terms of pan fixing it), but there IS a workaround.

For years, my download method has been somewhat different.  In my online
session, I download everything to cache, rather than trying to save files
directly.  Then I go back and go thru stuff a series at a time and decide
whether I want to save it or dump it then, saving it to its final location
right away, while I still have the metadata from the post (poster, date
and group posted to, subject line) available from pan to do so.  I don't
get the huge scratch dirs that many others tend to get, as I only save a
few files or series there at a time, moving them almost immediately to
their final save location.

Handling it this way, when pan's downloading, that's all it's doing,
saving the posts to cache only, not trying to decode them.  Thus it
doesn't care about the CRC32s.  It just downloads.  After it's thru
downloading and I go back to save stuff, if there's any trouble, I'll tell
pan to save the text not the attachment, and then go thru with uudeview
(which does yenc and mime as well) and have it do the decoding.  Where the
file is damaged, it recovers most of it, and I use par2 to repair whatever
damage is left.  Often, it's only a single block on a single file out of
the entire series covered by the par2s, and I need far less than half the
available par2 repair blocks.  (Of course, I downloaded them all along
with the original download to cache, so no big deal.)

The biggest caveat here is cache size.  As with a number of advanced
options, there's no way to set that in the pan GUI, but it's exposed as a
setting in preferences.xml, if you load it in a text editor.  I believe
the default is 10MB, sufficient for a text session or several, but
cache-busted pretty fast if you are doing binaries.  I have my binary
instance symlinked to a dedicated 12 gig partition so it doesn't interfere
with anything else, and have my cache size set accordingly.  It works
quite well, actually. =8^)

-- 
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