Ron F. wrote: > Regarding the issue of the FLAC Interactive streams stopping abruptly, > and often restarting many seconds later, and going backwards three or > four song to play all over again... > > Using Wireshark, I have seen different occurrences in which a running > connection will be closed and the LMS RP plugin will have to initiate a > new connection to RP: > 1. RP server, without warning, simply ends the connection; I assume this > might have something to do with load balancing between the various RP > servers. > > 2. RP server simply stops sending data to LMS, leaving the client > starved for data, LMS eventually closes the connection when this > happens, but it can take much longer than 30 seconds before LMS starts a > new connection. > > 3. RP server sends a new HTTP /1.1 200 OK (audio/flac) packet, I do no > understand the reason for this is, but LMS responds by closing the > connection; I don't know if that is necessary. > > 4. LMS server will send two or three [TCP Window Update] packets, over a > period of 3 to 5 seconds, after which no further data is received from > the RP server. I have seen as many as 80 seconds go by before the LMS > server then sends a [FIN, ACK] packet to abruptly close the existing TCP > connection and start over with sending a [SYN] to restart the stream. > LMS sends a TCP packet that looks like "HTTP 394 GET > /blocks/chan/1/4/280705-280708.flac HTTP/1.0" and we are off and running > again - often on a different server than before. What is interesting is > that I do then sometimes see packets received from the old server again > - I am not sure the old connection was terminated correctly. Question: > is the LMS RP plugin attempting to keep multiple TCP connections open > with RP servers? > > In all of these cases the result is the same - it is the responsibility > of LMS to initiate the new connection, and this usually takes too long > to happen. When faced with a closure of the existing TCP connection, it > sometimes takes LMS more than 30 seconds to start a new connection with > a TCP [SYN] packet sent to Radio Paradise. The buffer runs out during > this time, and the music stops. I don't know if this delay between > connections is intentional, or a bug either in LMS or possibly the Eth > stack? > > I don't know much about load balancing, but I imagine once connected to > a server the client should remain there for a long time? Should new > clients be sent to the least loaded server, and then remain there? Is > there a possibility that the RP servers are being attacked, causing some > of these problems? > > My first take on all this is that the RP stream is stopped or dies and > restarted too frequently. Before the buffer runs out however, is it > possible for LMS to take more aggressive action and close the existing > dead connection, and open a new one? Certainly waiting more than a > minute is too long. I am wondering if LMS restarted the connection > sooner, possibly we would not go backwards several songs? > > Once a new connection is established, the LMS server ACKs a bunch of > packets individually for a short while, and then TCP windowing takes > over ... and then after a while the problems return. > > Edit: I note that I see my connection to RP being tossed about between > three servers, when playing one of their FLAC Interactive streams. I am > located in California, and I believe the RP servers are in Florida - I > don't know if distance has anything to do with the issue at hand. > > Edit: I am also wondering if we could get the new connection going > sooner, we might stay on the same server used in the previous session, > and not go backwards several songs, but continue where we left off?
BTW on that topic, what I was able to establish is that the RP side closed the SSL session and it seems to be on a crypto error (I have to find my logs). It was linked to a pause made by LMS in requesting data. I even went all the way to write a very simple app in C and Perl getting the same URL from RP server and was able to demonstrate that if these few lines of code pause by ~5s from time to time (just sleep), then in most of the cases RP would end up the connection after a few pauses. When no "long" pause is made (say pause <5s), all downloads were successful. What happens as well is that with different openssl clients, the "long pause" effect was more or less problematic (say from 100% to 20% failed downloads) LMS 7.7, 7.8 and 7.9 - 5xRadio, 3xBoom, 4xDuet, 1xTouch, 1 SB2. Sonos PLAY:3, PLAY:5, Marantz NR1603, JBL OnBeat, XBoxOne, XBMC, Foobar2000, ShairPortW, JRiver 21, 2xChromecast Audio, Chromecast v1 and v2, , Pi B3, B2, Pi B+, 2xPi A+, Odroid-C1, Odroid-C2, Cubie2, Yamaha WX-010, AppleTV 4, Airport Express, GGMM E5 ------------------------------------------------------------------------ philippe_44's Profile: http://forums.slimdevices.com/member.php?userid=17261 View this thread: http://forums.slimdevices.com/showthread.php?t=111131 _______________________________________________ Squeezecenter mailing list [email protected] http://lists.slimdevices.com/mailman/listinfo/squeezecenter
