Phil <[EMAIL PROTECTED]> posted [EMAIL PROTECTED], 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 _______________________________________________ Pan-users mailing list Pan-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/pan-users
