timeout? that's unusual, i'm not sure what to
make of that - usually it just skips the track.
in most cases lame errors occur because it isn't
actually finding lame (check that LAME_BIN in
webplay.h matches where lame lives) or mp3 header
errors (this will syslog) but in both cases this
would skip the track and not timeout. there is
one other -- lame will silently reject some mp3s
as "bad" and just exit (i think that's in the FAQ)
but again, no timeout, just skip.
what does the playlist window say while it's
timeing out?
you may want to try the command line directly to
see what happens (from sh) ..
in your case:
lame --mp3input -b 96 "filename.mp3" - 2> /dev/null
i've never tested lame with less than 3.81 so be
aware of that.
also try a ps auxw | grep prog and find out if
getsong/playlist & lame are actually running.
and check your syslog.
let me know,
dave
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
ack, just for the sake of completeness (even tho i think your test proves it probably works) try the lame test again. two things: first, you're apparently using a csh variant 2>/dev/null was supposed to redirect standard error to /dev/null not write to file 2. second, and more importantly the - (write to stdout) is missing. if that didn't work. big oops.
for kicks throw in the -m j as well.
sh
lame --mp3input -b 96 -m j "foo.mp3" - 2>/dev/null
i'm rather at a loss, to be honest. i've never heard of this before which leads me to guess your client or lame. the debug & error handling around this area is kind of poor (partly because of popen, partly lame, partly me). we know it's getting the proper command line arguments, that it's being run, etc. could try something weird. in place of /usr/local/bin/lame put the script
#!/bin/sh
cat /some/dir/file.mp3
exit 0
that'll at least tell you whether it's lame.
the reason you have two lame pids is much easier. the first is the shell forked by the popen call made by getsong.cgi & it's this shell that actually runs lame. a ps -auxj would show they're related.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
mostly i'm curious as to how far right & how narrow we get with more and more replies.
if that lame command worked (wrote to stdout) then it's probably not a lame problem. i'm a little unclear if you put the simple shell script (cat /tmp/foo.mp3) into place as /usr/local/bin/lame and then tried to play in winamp. if that still didn't work then we'd know (as in KNOW) it wasn't lame.
try this, too.
go straight to apache and see what's happening.
$ telnet santaclara.dyndns.org 80
Connected to localhost.
Escape character is '^]'.
GET /cgi-bin/getsong.cgi?id=10840&song=1&br=96
<lots of crap>
and see what happens. if you get output then it's your client/network. if you don't, check your apache logs (error particuliarly) for something.
good luck.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
okay, so I connected via telnet 80 to apache.
Did a GET /cgi-bin/getsong.cgi?id=10840&song=1&br=96 which resulted in....
After a long long time (winamp throws the 'timeout message') I get <lots of crap> stdout
So... this _has_ to be either my client or network :(
I'm running a 100 switched lan at home with private dns/dhcp (private class c addresses) on the freebsd box. Hardware firewall box which is doing port forwarding of http.
Ugh... I'll do the test at home tonight and time how long it takes for the get request to <lots of crap> stdout.
\Ben
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Wrote some java code to fetch the URL, and added a timer. Wanted to see how long it took to get an answer from apache when br=96 is enabled in the URL string.
long timeNow = System.currentTimeMillis();
HttpURLConnection conn = (HttpURLConnection)the_url.openConnection();
InputStream is = conn.getInputStream();
long timeAfter = System.currentTimeMillis();
System.out.println("Time elapsed\n" + (timeAfter - timeNow)/1000.0 + " seconds");
C:\myjava>java BenURL "http://houdini.home.com/cgi-bin/getsong.cgi?id=10840&song=1&br=96"
Time elapsed
<b>154.64</b> seconds!
Durrr... maybe that's why winamp times out... I sure would.
Currently running apache 2.0.16.. will try 1.3.x and see if that fixes anything.
\Ben
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
yea, that doesn't sound like it's getsong.cgi (thank god ;-). to be sure i'd try some simple cgi (the stock apache printenv would work) & see if it stalls.
after that, get out the sacred chickens and watch them eat. divine from there.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
lame 3.70 on freebsd 4.3-RELEASE.
When I pick a different bit-rate, like 96k the stream will time out.
Going with a native bit rate streams fine.
I've tried different versions of lame, all with the same behavior.
any ideas?
\Ben
timeout? that's unusual, i'm not sure what to
make of that - usually it just skips the track.
in most cases lame errors occur because it isn't
actually finding lame (check that LAME_BIN in
webplay.h matches where lame lives) or mp3 header
errors (this will syslog) but in both cases this
would skip the track and not timeout. there is
one other -- lame will silently reject some mp3s
as "bad" and just exit (i think that's in the FAQ)
but again, no timeout, just skip.
what does the playlist window say while it's
timeing out?
you may want to try the command line directly to
see what happens (from sh) ..
in your case:
lame --mp3input -b 96 "filename.mp3" - 2> /dev/null
i've never tested lame with less than 3.81 so be
aware of that.
also try a ps auxw | grep prog and find out if
getsong/playlist & lame are actually running.
and check your syslog.
let me know,
dave
grep 'lame' webplay.h
#define LAME_BIN "/usr/local/bin/lame"
/* lame modes */
houdini# which lame
/usr/local/bin/lame
The client I'm using is Winamp.
// playlist
[connecting]http://santaclara.dyndns.org/cgi-bin/getsong.cgi?id=10840&song=1&br=96
// after about 15 seconds
[timed out]http://santaclara.dyndns.org/cgi-bin/getsong.cgi?id=10840&song=1&br=96
// some process status checking
houdini# ps -aux | grep lame
nobody 10846 99.4 0.9 7440 2400 ?? R 3:28PM 1:15.77 /usr/local/bin/lame --mp3input -b 96 -m j /usr/mp3/foo/foo.mp3 -
nobody 10845 0.0 0.1 624 256 ?? I 3:28PM 0:00.00 sh -c /usr/local/bin/lame --mp3input -b 96 -m j "/usr/mp3/foo/foo.mp3" -
houdini# ps -aux |grep getsong
nobody 10844 0.0 0.2 928 588 ?? S 3:28PM 0:00.07 getsong.cgi
// running lame from sh
houdini# lame --mp3input -b 96 "foo.mp3" 2>/dev/null
LAME version 3.70 (www.sulaco.org/mp3)
GPSYCHO: GPL psycho-acoustic and noise shaping model version 0.77.
Resampling: input=44kHz output=32kHz
Using polyphase lowpass filter, transition band: 10968 Hz - 11355 Hz
Encoding foo.mp3 to 2
Encoding as 32.0 kHz 96 kbps j-stereo MPEG1 LayerIII (10.7x) qval=5
Frame | CPU/estimated | time/estimated | play/CPU | ETA
50/ 6445( 0%)| 0:00:01/ 0:02:14| 0:00:01/ 0:02:09| 1.7323| 0:02:08
// correctly encodes this
houdini# file 2
2: MP3, 96 kBits, 32 kHz, JStereo
I tried later versions of Lame (3.88) and still go the same timeout behavior.
Is there any particuliar reason I have 2 lame PID's.. shouldn't it only be one?
Thanks,
\Ben
ack, just for the sake of completeness (even tho i think your test proves it probably works) try the lame test again. two things: first, you're apparently using a csh variant 2>/dev/null was supposed to redirect standard error to /dev/null not write to file 2. second, and more importantly the - (write to stdout) is missing. if that didn't work. big oops.
for kicks throw in the -m j as well.
sh
lame --mp3input -b 96 -m j "foo.mp3" - 2>/dev/null
i'm rather at a loss, to be honest. i've never heard of this before which leads me to guess your client or lame. the debug & error handling around this area is kind of poor (partly because of popen, partly lame, partly me). we know it's getting the proper command line arguments, that it's being run, etc. could try something weird. in place of /usr/local/bin/lame put the script
#!/bin/sh
cat /some/dir/file.mp3
exit 0
that'll at least tell you whether it's lame.
the reason you have two lame pids is much easier. the first is the shell forked by the popen call made by getsong.cgi & it's this shell that actually runs lame. a ps -auxj would show they're related.
This thread's starting to turn into a novel ;)
Yup.. you were right about csh. I changed shell to /bin/sh and re-ran:
lame --mp3input -b 96 -m j "foo.mp3" - 2>/dev/null
which writes to stdout.
The simple shell script behaves exactly the same.
#!/bin/sh
cat /tmp/foo.mp3
exit 0
Sigh... wish I could get this to work. My DSL upstream at home can only effectively serve 1 stream at a native bit rate.
I guess in the meantime I'll check www.sulaco.org/mp3 for any updates on lame. Perhaps a newer version might behave correctly.
I really appreciate you taking the time to help me debug this.
regards,
\Ben
mostly i'm curious as to how far right & how narrow we get with more and more replies.
if that lame command worked (wrote to stdout) then it's probably not a lame problem. i'm a little unclear if you put the simple shell script (cat /tmp/foo.mp3) into place as /usr/local/bin/lame and then tried to play in winamp. if that still didn't work then we'd know (as in KNOW) it wasn't lame.
try this, too.
go straight to apache and see what's happening.
$ telnet santaclara.dyndns.org 80
Connected to localhost.
Escape character is '^]'.
GET /cgi-bin/getsong.cgi?id=10840&song=1&br=96
<lots of crap>
and see what happens. if you get output then it's your client/network. if you don't, check your apache logs (error particuliarly) for something.
good luck.
hmm...
okay, so I connected via telnet 80 to apache.
Did a GET /cgi-bin/getsong.cgi?id=10840&song=1&br=96 which resulted in....
After a long long time (winamp throws the 'timeout message') I get <lots of crap> stdout
So... this _has_ to be either my client or network :(
I'm running a 100 switched lan at home with private dns/dhcp (private class c addresses) on the freebsd box. Hardware firewall box which is doing port forwarding of http.
Ugh... I'll do the test at home tonight and time how long it takes for the get request to <lots of crap> stdout.
\Ben
Update:
Wrote some java code to fetch the URL, and added a timer. Wanted to see how long it took to get an answer from apache when br=96 is enabled in the URL string.
long timeNow = System.currentTimeMillis();
HttpURLConnection conn = (HttpURLConnection)the_url.openConnection();
InputStream is = conn.getInputStream();
long timeAfter = System.currentTimeMillis();
System.out.println("Time elapsed\n" + (timeAfter - timeNow)/1000.0 + " seconds");
C:\myjava>java BenURL "http://houdini.home.com/cgi-bin/getsong.cgi?id=10840&song=1&br=96"
Time elapsed
<b>154.64</b> seconds!
Durrr... maybe that's why winamp times out... I sure would.
Currently running apache 2.0.16.. will try 1.3.x and see if that fixes anything.
\Ben
yea, that doesn't sound like it's getsong.cgi (thank god ;-). to be sure i'd try some simple cgi (the stock apache printenv would work) & see if it stalls.
after that, get out the sacred chickens and watch them eat. divine from there.
Went ahead and removed apache 2.0.16, and built/installed 1.3.20 from the ports tree.
it is now working properly! :)
thanks again for the help debugging this.
\Ben