This is very helpful advice. Yes, I have a feeling this issue I'm seeing is related to a specific machine; which happens to be my squeezebox server as well. I did install a TCP/IP hack to increase the limit of TCPIIP connections since I use this machine for several different TCP/IP related services. However,that should help things, but make things worse.
Ever since I added secondary accounts to slacker and sirius radio on mysqueezebox.com, I noticed the problem happens much less frequeently (it used to be sometimes every 5 minutes.. now its every 45 minutes - 1 hour)...even longer if I dont do anything TCP/IP related. I guess I could try to increase the buffer to a very high value; including the timeout to see what kind of affect it has. The condition I'm pointing out is definitely not that bad; and in fact, works great. However, I have so many internet services running on this machine, you probably wouldnt believe it... I have 12 TV tuners on this machine serving through the internet, ASP.net based apps, FTP, and many other TCP/IP based services. The good news is I inreased the reliabilty considerably by adding 2 accounts (one for each client). I dont know why that helped, but there's not question that it did. I will also take a closer look at tcp/ip based activity using my favorite utility TCPView; which works okay. Thank you for your support for this product with minor enhancements. I dont expect any major changes. As long as logitech doesnt abandon their customers who bought the classic squeezebox hardware devices, I think us softsqueeze users will be fine. bpa;515339 Wrote: > As I said before I cannot test these services as they are not available > to me. > > Softsqueeze is not my code - I just do some basic maintenance on it to > keep it ticking over until SqueezePlay is ready (which is taking longer > than expected). > > Changing Softsqueeze to add some additional status would probably > require changes in SBS which I cannot do so it is unlikely. Spoftsqueeze > is a strange beast, within SBS it is subclassed of a Transporter model > as it was used to test new products graphics but its audio/network is > not quite an SB2 so it has a minimal implementation of the slimproto > protocol especially since changes in 7.3. > > Your best bet would be to isolate the problem. I think you need to > record sessions (probably on both sides of local SBS) using something > like wireshark (was Ethereal). Note time when recording started and the > time when the problem occur - examine the recording forensically at the > problem timepoint and go backwards. I've done this a number of times > tracking rare protocol events which required recordings of many hours - > it is tedious but that is what it will require. > > From your description, I think the problem could be associated with a > TCP reset which is used to clear half-open TCP connection but often > still ends with a half open connection but stuck. Applications need to > look for the ECONNRESET error but often with "don't block on read" on a > TCP socket - the Reset error code is overlooked as code assumes there is > no data to read. I think there could be issues handling ECONNRESET in a > proxy configuration (e.g. should a RESET be propagated or absorbed or > link closed by the proxy). > > To get started, I suggest looking at the Reset count in the TCP > connection statistics (e.g. netstat -s) on both sides of the SBS and > from both ends (i.e. monitor 4 sets of counts). The Reset count usually > only increment at beginning and end of connections. See if Reset count > is increment around the time you have a "hiccough" in your audio. -- mkanet ------------------------------------------------------------------------ mkanet's Profile: http://forums.slimdevices.com/member.php?userid=7965 View this thread: http://forums.slimdevices.com/showthread.php?t=62060 _______________________________________________ plugins mailing list [email protected] http://lists.slimdevices.com/mailman/listinfo/plugins
