[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Pan-users] PAN best newsreader under Linux but ...
From: |
Duncan |
Subject: |
Re: [Pan-users] PAN best newsreader under Linux but ... |
Date: |
Tue, 31 Dec 2002 03:48:04 -0700 |
User-agent: |
KMail/1.5 |
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