[BL] sdf mail problem
sam.acorn at gmail.com
Sun Jan 14 03:57:29 EST 2007
On 13/01/07, sindi keesan <keesan at sdf.lonestar.org> wrote:
> For the past four days or so it has been taking about 60 seconds to send
> mail using pine or mutt. Someone made some comment in the 'bboard' that I
> could not follow, about smtp and spam causing the problem. 'mail' sends
> immediately - can I access my inbox with it somehow? I can use it to
> send mail, but typing 'mail' tells me keesan has no mail.
> Is there some
> feature in mutt or pine that can be turned off to fix the problem?
if ppl are using the same smtp server as you for spam it would cause
delays... but if you are using sdf i doubt spam has any say in the
matter... sending mail using 'mail' probably falls to a background
process that takes 60 seconds that you dont see... if thats not the
case then something else is set wrong in pine/mutt or they are having
problems at whatever smtp server you are using... -or- your modem is
getting something hung in its data pipe... what state is 'CS' in on
those 60 second delays?
in pines settings look for an option labeled 'assume-slow-link'... try that...
> I have not figured out how to use bboard.
not familiar with that one...
> I cannot receive list mail at my other shell account (it is too slow for
> ibiblio) and would hate to use webmail.
but yet.. another reason to use it... ;)
> For now I am replying to a minimum number of postings, and going off to my
> other account to read emails for 60 sec each time I post something (or
> reading a book).
> While I am here, could someone explain how listening to a wireless
> broadcast of music over the internet uses more resources than listening to
> a wireless broadcast of FM music?
fluff from lee on that one? lol... ignore it.. it doesnt.. your
computer would use the same amount of power waiting for 'press any key
to continue' as it would playing an audio stream... as for the other
systems involved in getting a stream to you... the mp3 encoder (which
can be done with a low end home pc) is still running whether you are
listening to it or not... so no power saved there... as for the
routers along the backbone of the net that are carrying those TCP
packets full of mp3 (or other) data to you -- if you arent using them
someone else is... and since the monitor is on whether you are
listening to music or reading your email (or more than likely both)
then that has no factor either... and heres a kicker... considering
that you need your monitor to see the email but not to hear the music
you can turn your monitor off while listening and use less power
listening to internet radio than you would reading email...
if lee is factoring in the 'retransmission' part then the inefficient
area is the 1000+watt -limited coverage- vacuum tube based
transmitter(s) that the FM station is using...
if he would have said satellite radio (XM or sirius) which covers the
whole continental USA with 3 solar powered satellites then i -might-
have given it to him...
btw, check into more web-centric stations than retransmitted FM...
less talk (or no talk) and no way for anyone to claim any
"inefficiency" unless you are playing mp3s with the univac...
as far as 24k streams cutting out on you on 56k thats a buffer
problem.... a problem as in its not big enough... i use a buffer of
6mb (yes 6 megabytes) for internet radio... gives me more 'wiggle
room' when visiting websites and when the phone line changes its mood
(modem retrain)... may seem a bit big but it works... 1 mb may be
better to start with tho as mplayer takes a while before it starts to
play when using a buffer of 6mb (i normally use foobar2000 on windoze
since i prefer AAC+ streams)... start at 1mb then work your way up if
you still get cut-outs...
mplayer http://184.108.40.206:4802/ -cache 1024
make sure when it starts playing that stream it uses a sample rate of
16000hz (stereo)... mplayer uses a buggy version of the mpg123
decoder... which keeps wanting to start at 11500... (errors like; 'big
values too big!' & 'cant rewind stream by xxx bits!')
"When you've done something right, no one will be sure you've done
anything at all." -- Futurama
More information about the BasLinux