Very interesting, and very strange.
I've actually heard of this happened from a couple of other folks, and we've never been able to determine if it's a ScannerCast problem or a RR server problem. In each case, there's been an underlying connection reset... such as the DSL or cable modem disconnecting and then reconnecting. This is probably due to the ISP trying to throttle bandwidth and limit streaming (very annoying). Each time, there's absolutely nothing in the ScannerCast log... ScannerCast never sees the connection loss.
Soooo.... please check to see if your cable or DSL modem is disconnecting and then reconnecting. If so, this is a situation we've seen before, and could be caused by one of 3 things:
• Your connection recycled so quickly that TCP/IP managed to recover the connection without telling ScannerCast, and ScannerCast is sending 2 packets per second of data to RR, and RR is acknowledging them, but RR thinks your connection is down. This would be a bug at RR (such as with the Icecast server). Given the number of feeds running at RR and the length of time Icecast has been used (in the whole world) this doesn’t seem likely, but it is possible.
• There could be a very subtle and as yet undetected bug in ScannerCast that only a small number of people are seeing because of issues with their ISP and the speed that their circuit gets recycled. This is possible, but from looking at the code this seems to be unlikely. Of course, that’s why they call them bugs… ScannerCast is certainly built to handle any situation I can anticipate, but by definition can’t handle things I didn’t think of.
• The Windows networking components that ScannerCast uses could be exceptionally confused, and ScannerCast is sitting around waiting for a message to be sent by TCP/IP that never times out. This would be a bug in either the .Net Framework or Windows TCP/IP protocol – possible, but extremely unlikely, but it wouldn’t be the first such bug discovered in history.
Soooo… if you could… Check to see if your underlying network connection (cable or DSL modem) is "recycling." Then, if it is, reproduce the problem and let me (and hopefully one of the RR admins) look at your feed WHILE the problem is occurring. If we confirm that RR thinks your feed is down, but ScannerCast thinks your feed is up (as shown in the Status tab) then I can create a special version of ScannerCast that’ll be able to tell us whether ScannerCast or RR is correct.
Interesting problem,
Peter
K1PGV