paul- wrote: > LMS uses perl IO::Socket::SSL, which then uses the system openssl for > connections (I wonder if the perl module version makes a difference), > however LMS is only used if you are using proxied streaming. If the > player supports SSL, then the players SSL is what matters. If the > player does not support SSL, then LMS will automatically proxy. > However, I'm not sure how SSL plays into this. I was doing a test over > the weekend, and the connections to RP were _not_ secured. The music > was streaming over plain HTTP. (Both in the interactive and continuous > stream) > > When playing the continuous stream, data is fed to the player at a nice > controlled pace from the server. When the interactive stream is played, > the server tries to send the whole file all at once, so the file fills > the player and network receive buffers. I wonder what happens if you > increase your player buffer to hold more data.
Thank you for this. I do not understand how SSL works; I have some reading to do. From my use of Wireshark this past weekend and watching RP FLAC packets on their way to LMS, I did not see anything related to SSL - but I did not understand the implication of that at the time. Playing with different releases of openssl was not going to make any difference, and indeed - it did not. I have tried playing with the LMS network settings in the past, and setting "Radio Station Buffer Seconds" to it's max: 30, has not make any difference. Enabling "Proxied Streaming" never made much if any difference either. Does Proxied Streaming cause LMS to create an additional buffer on the server? Regardless, if the interactive stream is attempting to download an entire file all at once, then this sounds like an ftp download! If every time Bill does a station announcement represents the start of a new file, then we could be talking about a GByte of data. Ouch - I am surprised this works as well as it does! There are all kinds of timeouts that might occur causing this to fail, and the RP server attempts to restart the download ... from the beginning. When streaming Interactive, wouldn't the RP plugin then need to offload all this data into a temporary file? A buffer in memory big enough to solve the issue would be impracticable. The TCP Rx buffer is going to fill and I imagine timeout if the plugin does not read out the data and store it somewhere. Is the LMS RP plugin relying on the network stack to control the connection, to close the connection for instance when there is a problem? If LSM RP plugin is only reading sufficient data out of the network stack to fill a 30 second buffer, then I doubt that buffer size is going to matter if the RP server is trying to shove a file's worth of data to LMS. It also seems likely that increasing the size of the TCP Rx Buffer in the LMS server network stack is not going to help either. I imagine then the only solution is that the RP plugin needs to be able to store a LOT of data into a temporary FIFO file on the server's HDD. While writing this, I have experienced two long delays, followed by restarts in the RP Main FLAC Interactive stream. *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
