Broadcasting Persistence (IceCast)

bostonfreeradio

New member
We are trying to migrate our broadcast from Studio365 (not long for this earth) to having RadioBoss broadcast directly to an IceCast server we've setup ( http://192.241.246.209:8000/ )

The broadcast will connect and work fine, but occasionally drop out and never reconnect, and not give any helpful reason why (details in the screenshot).

We are using the default IceCast setup where there is no real initial "mount point", meaning "/stream" gets created on the first connection to :8000. That might have something to do with it. I know if I enable/disable the broadcast a few times it picks up with no change required on the server side.

It also will say "active" and "ON AIR" even if we disconnect the network cable from the PC.

Any advice to help stabilize this is appreciated, we're trying to pivot on a dime!
 

Attachments

  • Screen Shot 2016-01-29 at 9.46.20 AM.png
    Screen Shot 2016-01-29 at 9.46.20 AM.png
    1,008.5 KB · Views: 630
  • 12592350_10103279323660982_6452572307940128548_n.jpg
    12592350_10103279323660982_6452572307940128548_n.jpg
    36.2 KB · Views: 522
Looks like it's probably an issue with IceCast persisting the default /stream mount point, but it still remains that RadioBoss is not giving good information about the connection.

IceCast's error.log:

[2016-01-29  15:21:13] WARN admin/admin_handle_request Admin command listclients on non-existent source /stream
[2016-01-29  15:21:34] WARN source/get_next_buffer Disconnecting source due to socket timeout
[2016-01-29  15:21:34] WARN fserve/fserve_client_create req for file "/usr/share/icecast2/web/stream" No such file or directory
[2016-01-29  15:21:35] WARN fserve/fserve_client_create req for file "/usr/share/icecast2/web/stream" No such file or directory
[2016-01-29  15:22:05] WARN source/get_next_buffer Disconnecting source due to socket timeout
[2016-01-29  15:22:14] WARN admin/admin_handle_request Admin command listclients on non-existent source /stream
 
bostonfreeradio said:
The broadcast will connect and work fine, but occasionally drop out and never reconnect, and not give any helpful reason why (details in the screenshot).
Is there an error message like "Server connection closed" in the log? I don't see any in the screenshot posted.

It could be that your server is set up incorrectly. I'd suggest you to try the trial server at http://www.radioboss.fm - just test if it works fine or not.

Sometimes streaming problems are introduced by antivirus software - if you're using one, try disabling it.

bostonfreeradio said:
It also will say "active" and "ON AIR" even if we disconnect the network cable from the PC.
The ON AIR merely indicates that broadcasting is turned on, it doesn't indicate the actual connection state.

bostonfreeradio said:
[2016-01-29  15:21:34] WARN source/get_next_buffer Disconnecting source due to socket timeout
From this line, it appears that Icecast  disconnects you because no audio stream is being sent. In your settings I noticed that you use Input 1 as sound source. Try changin it to Audio Mix - in this case it will broadcast everything that you play in RadioBOSS, while Input 1 option is used to use sound card's input as broadcasting source.
 
Thanks for the reply!

1) We never see any "server connection closed" in the log at all.

2) It'd be nice if it represented the actual connection state. :)

3) Input 1 is our soundcard's input, which is the output from our broadcast mixer. For troubleshooting, I can test with just the audio mix-- but this doesn't help us long-term.
 
bostonfreeradio said:
3) Input 1 is our soundcard's input, which is the output from our broadcast mixer. For troubleshooting, I can test with just the audio mix-- but this doesn't help us long-term.
If the input is set up incorrectly, then RadioBOSS will not send any data to the server, it also won't be able to detect that the connection was closed by the server for inactivity (this is how network protocols work, if there's no activity, then there's no way of telling that the connection is actually still alive).

For actual connection state, it's a bit more complicated: for instance, there could be more than one broadcasting encoders, and if one if them is connected, while another disconnected - what should ON AIR show?
 
Back
Top