Well if you telnet to the port and it is printing the binary
to the screen, then the server works. That is all it does.
The whole purpose is to print binary to the socket.
I would bet that the problem lies in your mp3 player, what
player are you using and what OS are you using. I
have been using this server in some form or another for about
a year now, so I nearly positive that the problems you are
having are not related to the server code (unless they are
OS specific, in which case I probably cant help).
But if you can track down the problems and the cause does
lay in my code, then let me know and I will make the corrections. | [reply] |
Hi folks,
I've been experiencing the same problem that was reported earlier ("it seems to be going very fast"). I'm on Win32 (both NT4 and Win2k) and played around with the script for a while before figuring out a fix. It looks like a:
BINMODE(SONG);
fixes all. I also took out the forking-ness of the server, just to simplify the debug process, but I'm sure that's OK.
With the fix in place, the code segment now looks like this:
<text cut>
...
#what song are we playing
warn( "play song: $song\n");
#open the song, or continue to try another one
open (SONG, $song) || next;
#### NEW CODE ####
binmode (SONG);
#### END NEW CODE ####
my $read_status = 1;
my $print_status = 1;
my $chunk;
....
<end cut>
I think this fix suggests that somewhere in the MP3's being streamed, read() was encountering what it thought was an EOF, where in fact it was misinterpreting the data. Am I right? (I guessed at binmode, read the cookbook, then understood)
Hope this helps,
Brainiac | [reply] [d/l] [select] |
Thanks for the debugging!
I dont use windows, so I never think about binmode.
That routine doesnt hurt on unix, so I will add it into
the server code for all to use.
-perlmonkey
| [reply] |