No stream heard

[stefandz]

Hi everyone

I've spent quite a lot of time trying to sort this out myself, and I feel like I'm probably doing something dumb, but here goes!

I have node 0.8 installed and Airtunes installed (AFAICS) correctly, in as much as it is happy enough to run without errors. However, trying to stream to Airfoil speaker results in no audio being heard, and the connection only lasting momentarily. Airfoil gives an error "A connection error occurred. Error during read: Connection reset by peer (54)". However, I can happily connect via Airplay to Airfoil using my iPhone. I have shown what's going on in a YouTube video (sorry about dreadful compression).

https://www.youtube.com/watch?v=aK6zTZCyclY

A few extra facts:

1. Yes, I'm doing this in a VM, but it's only for ease of shooting the video - the same happens when I use a whole different machine.
2. I'm using Node 0.8 because I saw in another Issue that not doing so had caused problems.
3. I've double-checked that the Airfoil port is set to 5000 (used MDNSD and snooped using Wireshark during a working session streamed from my iPhone).
4. Although I'm using play_stdin.js in this example, I have also had the exact same behaviour when using play_ffmpeg.js.

Please let me know if I'm doing something really daft - surely this must work for lots of other people?

[Jeroen-R]

Not a node expert either, but I experienced the same problem and have found a workaround.

The problem appears to be that it is somewhat difficult to make node scripts run indefinitely. In you case it probably works fine, it just finishes execution very quickly.

Change the 1000 (1 second) parameter in the following code example to a larger value.

setTimeout(function () {
  console.log('stopping');
  airtunes.stopAll(function () {
    console.log('all stopped');
  });
}, 1000);

There are better ways to do this, just search for make node application run permanently

[stefandz]

Thank you for this, and sorry for taking so long to get back to you (busy couple of weeks!). However, you're quite right - this is a good starting point workaround. I think it comes down to the handshaking between the Airplay source (us, in this case) and the sink taking a while. A value of 10000 seems to have no ill effects for me. Possibly a consideration for a future permanent code change if it doesn't negatively impact anyone else?

[fritz-fritz]

Also ran into this issue... this certainly fixed it. I was pulling hairs out assuming that the example should work..