Re: [Pan-users] PAN best newsreader under Linux but ...

[Duncan]

On Mon 30 Dec 2002 16:18, Stuart Pettie posted as excerpted below:
> I can't seem to get the "Get all headers & bodies" to work, never seems to
> store the articles for offline reading.
>
> What is the function of the cache and what should I set it to for use ?

When I switched to Linux and PAN, this confused me a bit as well, particularly 
in large binary groups, like the MP3 groups, where I could see it d/l, but it 
would never get the entire thing saved to cache, so I could go through the 
songs offline at my leasure.  Of course, that was back when the max cache 
size was 1 GB, which I think had something to do with it.  What was happening 
was that it would start deleting old parts before the download was even 
finished, presumably because the cache was full.  I never tracked exactly 
why, but I'm guessing, due to later usage figures of 2 gig/session downloads 
sometimes, meaning that 1 gig was certainly a problem.  Actually, I was the 
one who put in the request to up that max, to at least the 4 gig I was 
editing the config file manually by then to run, and was quite thrilled to 
see it upped to 20 gig max, for the next beta.

Assuming you aren't talking about text groups and some new bug <g>, but are 
rather talking about the problem I was having as described above, there are 
two possible options.  One, you can up your cache size if necessary, to be 
sure it's large enough to contain all messages you are going to d/l for the 
session.  It's possible this won't work quite as expected, however, due to it 
d/ling only the first part of multi-parts, sometimes, in my experience.  That 
isn't quite as I expect, but I haven't troubled myself to much about it, 
because I use solution two, below, most of the time, and have a fast enough 
connection that it isn't a huge problem when it does happen.

Two, the solution I came up with back then, and still use most often on groups 
where I expect multi-parts, set PAN to SAVE the multi-part attachments, not 
just d/l them.  IOW, select the messages you will be saving the attachments 
to, and rather than hitting download, hit save attachments (shift-s, by 
default).  Make the place you save the attachments to not your ultimate 
storage location, but an intermediate directory location, and rather than 
browsing the messages in PAN to decide what to keep, then, browse the fully 
assembled files in the intermediate location, either deleting them or moving 
them to the final location as appropriate.  Actually, this is better than the 
way at least I used to do it in OE on MSWormOS for a couple reasons.  One, 
you have the files actually saved and decoded by the time you sort through 
them, so you don't have to do that as a separate step.  Two, encoded binary 
files take up much more space than the decoded files, so it's more efficient.  
The only problem doing it this way is that you lose the meta-info provided in 
the thread itself, so reassembling albums, say, from individual song files, 
may be a bit harder.  However, as long as nfo or similar contents files are 
included, or if the actual file names include artist and album info, that 
isn't impossible.

-- 
Duncan
"They that can give up essential liberty to obtain a little
temporary safety, deserve neither liberty nor safety." --
Benjamin Franklin