Upstream dropping... alot!
 

I'm streaming @ 128k using Nicecast through a Netgear WGT624.v2 router over a dynamic DSL line. The SC server is 1.9.5 for Linux.

The router is correctly set to keep the line open (I figgured the constant upstream of data would do that) but the line drops sporadically. It can stay up for a day and a half or it can drop after 30 minutes. There is no obvious pattern.

It also appears that the drop is only affecting the upstream because when I see that the stream is down, I can open a browser on that machine an connect to the net with no problem.

It is also worth mentioning that the connection will also drop when I connect direct to DSL with no router.

The SC stream being lost takes a little more work to recover. Nicecast tries to reconnect, but returns a "login failed" error. The only way to get the streams back up is to ssh to the server and kill the PID, then restart it. I also have to do the same to my relays.

What should I be looking at to run down this problem? My first instinct is that the DSL Dyn IP is changing, causing a drop. DSL is with SBC...could they be watching my datastream? It's only 128k and that is the ONLY use that line gets. I don't even DL software updates on that line.

Do you think the issue could be the remote server? I'm assuming you're using a remote server because you mention only using 128k.

I am also looking at that possibilty--in fact HIGHLY probable. What I know is this:

DSL connection is up...
DSL drops...
Nicecast is doing its job: Trying to reconnect when the connection is lost...
DSL is back up...
The remote server is not allowing Nicecast to login again.

I have to kill the sc_serv PID and relaunch SC.

THEN Nicecast can login.

SC isn't releasing the port after the connection is lost so it must think Nicecast is still connected.

I have a feeling that this problem coincides with my server having to be rebuilt. I originally had RedHat 9 and didn't have this problem. When there was a security issue, my host rebuilt the server and installed Fedora--they didn't ask they just changed it.

Do you notice if the IP of your source changes during this process -- You want to determine if it is in fact an issue with your broadband connection [a brief connectivity loss followed by an IP change would be a sure indication that would not effect browsing], or if there is network congestion somewhere between you and your DNAS.

Since you can still browse -- connect to the DNAS station page [admin.cgi] and kill the source -- this will allow a more graceful recovery, you could also decrease the DNAS source idle timeout, so that the DNAS drops the connection sooner after the source stops sending data -- this will allow you to know when the problem occurs sooner, and your NiceCast may be able to recover faster [it should also have a reconnection timeout that you can decrease].

Lastly, but probably the most important -- You're streaming at your source upload limit -- not likely to work over time -- I would guess that at 96k you would have much better luck. In your case, the source is under-running -- to do what you want, your connection would have to be 110% perfect every minute of every day -- not likely for residential broadband.

Source idle timeout is currently 0s. A far as upload speed goes, I'm fine. I have a 384 upload which usually tests more in the 425 range.

well thats very funny as i had the same problem :WITH THE SAME ROUTER!: i fixed it by assigning the server a new local ip on the router

Zero may be too small for the source idle timeout -- sometimes a zero value indicates NO TIMEOUT -- try 5 seconds.

I'll add that your problem may be that your source is not automatically reconnecting as well -- the DSP has both a Reconnection time value and a logical (yes/no) "Reconnect on connection Failure" that will tell the source to reconnect when the link fails -- you want both to occur.

The DSP reconnect time should be greater than the DNAS value to prevent the source from trying to attach to the DNAS before it closes the stale (idle) source connection.

there is info on this in the nicecast forum @ audio hijack. I think its a bug. (one of our djs uses it)