Some more information, not really progress unfortunately
- I've tried adding SO_KEEPALIVE to maintain socket at the TCP level => no impact - Confirming the above, I've carefully logged the streaming process between LMS and the player: the player does not do "long suspend" of the data request due to some buffering. There is a regular flow of data, instead it's LMS that closes the socket with the player - More interesting and probably why I did not see that before: this does *not* seem to happen on my Windows version, where I did the tests before. I've now listened to more than one block without interruption, which has not happened *at all* today on my Pi3: all blocks have been interrupted. - I've looked more at the option to hide the reconnect inside the HTTP/S core logic and I don't think it's possible. The socket created when starting a song is used all the way up by the SongController, so if it closes, it can be re-open "in the background". The re-opening would have to be done very high, in the StreamingController. 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=108189 _______________________________________________ plugins mailing list plugins@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/plugins
