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

[Ade]

Hi all,
this is my first post so apologies for any unintended breaches of list 
netiquette.  I've searched the user-manual (didn't take long!) and the 
archives of this list but I can't find the answer to my question so I'm 
hoping some kind soul will help me out on the list.

I'm trying to access MP3 files from alt.binaries.sounds.* and am finding it 
difficult.  I've worked out that you have to select "Don't save attachments" 
for pan to save the attachments but I'm not sure how to assemble all the 
parts into one mp3 file.  I tried cat and then downloaded & installed 
yydecode which produces a short clip of sound.  I'm guessing this is the 
contents of just one of the parts.

Apologies if I'm being thick but just how do I download useable, entire mp3s 
from usenet?
I'm running pan 0.11.4 on RH7.1.

Many thanks in advance for your time.

Regards

Ade 
On Tuesday 31 Dec 2002 10:48 am, you wrote:
> 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.