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. *Living Room:* SB Touch + DIY PSU > CI Audio VDA.2 DAC + VAC.1 PSU > VRX.1 cables > Emotiva XSP-1 Gen 2 preamp + XPA-DR2 amp > Blue Jeans cables > B&W 804 speakers *Laptop:* System76 Galago + Ubuntu 16.04 + Squeezelite + Material Skin > ifi USB iSilencer > Audirect Beam DAC > Senn IE 80 earbuds *Bedroom:* Pixel 3a Phone + SB Player + Material/mobile > Bose SoundLink Revolve *Server:* Puget Systems Serenity + Ubuntu 18.04 + LMS 7.9.2 *Music:* Personal FLAC, Radio Paradise FLAC, Qobuz, Spotify ------------------------------------------------------------------------ Ron F.'s Profile: http://forums.slimdevices.com/member.php?userid=5616 View this thread: http://forums.slimdevices.com/showthread.php?t=111131 _______________________________________________ Squeezecenter mailing list [email protected] http://lists.slimdevices.com/mailman/listinfo/squeezecenter
