As a pre-note: everything works perfectly on my local OS X installation.
After grabbing the latest code from the repo and setting this up for my radio website (code is being used here: https://github.com/pedromtavares/radio/blob/master/lib/decoder.js (line 19 might be commented so I could leave the radio working until I fix this)), the encoder immediately fails and prints out this error:
AssertionError: false == true
at Parser. (/usr/local/lib/node_modules/lame/node_modules/strtok/lib/strtok.js:366:9)
at Parser.emit (events.js:67:17)
at Parser.write (/usr/local/lib/node_modules/lame/lib/parser.js:133:8)
at Encoder.ondata (stream.js:38:26)
at Encoder.emit (events.js:67:17)
at afterWrite (/usr/local/lib/node_modules/lame/lib/encoder.js:147:12)
(it wasn't printing anything until I updated the code from the npm version to the repository version)
On a side note, I uploaded a .wav to the server, ran the test-encoder.js file to an .mp3 output file and it encoded perfectly.
As a quick test, try not using the Encoder class (replace it with the child process version you had before), but do use the parser. Let me know if that works.
Also, note the an MP3 client could connect to your server after a 'header' event, but before a 'frame' event, thus causing a missing header at the start of the mp3 file. A solution would be to keep two counters on each client of the number of frames and number of headers sent, and make sure that a frame is sent only when the header count is greater than the frame count :)
Yep, changed the code to that and it worked, here's the commit (last 3 changes): pedromtavares/radio@0cb406b
I guess that narrows it down by a bunch huh :P
Thanks for the tip! Will implement that after we get this solved :)
Ok well that's... ok... I guess.
Can you try putting the Encoder back in (obviously there's some bugs with it still..). But I'm most curious about the size (.length) of the chunks going into the encoder, as well as the size of the chunks coming out and going into the parser. If you could give me a log of those as they are processed it would be much appreciated!
From my local: http://cl.ly/0N3C2K0W231G28282K1b
From the server: http://cl.ly/063a1D3n040z1C1Q2z2K
Seems like nothing is coming out.
Pedro, thanks for taking the time to help debug. I haven't been able to reproduce your problems unfortunately. And it's even stranger considering the fact that you said the test-encoder.js file worked on your server. Anyways, I'm not gonna close this one yet, but I'm starting to think that it might be a problem in your application logic rather than this module.
If you still think it's the module, could you start littering console.error() statements all over the Encoder class (specifically the _process() function)? Let me know if you uncover anything else.
And I'm almost certain it has something to do with lame, it makes no sense for it to work perfectly locally and not work on production, considering it's the same exact environment except for the OS and the lame version (on my local it's 3.98.4). But those logs were of great use, because now we can know for sure that the problem is around Encoder and that it's not being written on, but yeah I'll add those calls and see what I can find.
You sure that initial stack trace is of no use? Since strtok is a depedency, we could both be right about our code and the problem could be it haha :P
Well I don't know how you got that original stack trace. It seems like that might happen if a 0-length buffer gets written to a strtok parser, but that wouldn't make any sense in your case since the Encoder isn't spitting out any data :p
Anyways, littering console.error() over the _process() function would still be very helpful (both before and after the afterRead function). Thanks again.
And more specifically, strtok is only used on the Parser class.
@pedromtavares I'm gonna close this one. The node-lame code base has changed drastically since this was opened. Please open new issues for any current issues you have with the v1.0.x release!