Home of the Squeezebox™ & Transporter® network music players.
Page 2 of 5 FirstFirst 1234 ... LastLast
Results 11 to 20 of 43
  1. #11
    Senior Member
    Join Date
    May 2008
    Location
    Canada
    Posts
    5,109
    Quote Originally Posted by Raymond Woodward View Post
    Too many users - not enough bandwidth provided by RP ...
    I did a ton of analysis on that, including writing Perl scripts and C programs to simulate the client behavior. All the logs drove me to the conclusion that something happens at the crypto level which causes the server to close the connection due to a crypto failure. Happens with certain patterns of streaming (high/low water which force pauses - not very long, just a few sec regularly, AFAIR). The very basic Perl/C which was just doing a "GET" on the stream was able to reproduce that 100% with the proper pausing schema and 0% with a nice "continuous" flow. It was also less visible with certain openssl versions
    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

  2. #12
    Senior Member
    Join Date
    Feb 2009
    Posts
    281
    Quote Originally Posted by Raymond Woodward View Post
    Too many users - not enough bandwidth provided by RP ...
    A stampede of new listeners just when the site got "updated"? Don't think so.

  3. #13
    Junior Member
    Join Date
    Feb 2013
    Location
    Portlandia
    Posts
    6

    RP Buffering

    Quote Originally Posted by Ron F. View Post
    I quite using the RP FLAC Interactive streams; it is a great idea but it simply doesn't work. I use FLAC Regular, which still hiccups occasionally, but at least it keeps moving forward. If I don't want any hiccups, then I use a 320 kbps stream. It isn't just RP, occasionally I get hiccups trying to stream FLAC from Qobuz.
    I'm with you. The RP plugin for LMS has become un-listenable on my Transporter. I can stream flac to my phone and computer, no problem at all. I don't believe RP's bandwidth is the issue (as I once did). I'd rather listen through the Transporter though. Hoping for solutions!
    Transporter -> Behringer DEQ2496 -> NAD M2 -> Paradigm Reference Studio 60 v.5s -> Treated Listening Room

  4. #14
    Senior Member
    Join Date
    Jan 2009
    Location
    Sor°, Denmark
    Posts
    679
    If you have buffering problems, try to set sound as "Streaming through Proxy". Works perfect here.
    Callesoroe
    Living room: Transporter, Tact RCS 2.2X digital preamp, Martin Logan Vista speakers, AMPS(Icepower): Acoustic Reality Ear Enigma PLUS(PANELS), Acoustic Reality Ear TWO MKII(Bas)
    Kitchen: Transporter - Prodipe Pro 5 active bi-amp speakers. Bedroom: Receiver+UE boombox, Kids: Receiver+Active speakers, Guestroom: Touch - Bencmark DAC1, JBL LSR305 active speakers , TIDAL HIFI flac streaming.
    http://www.last.fm/user/callesoroe

  5. #15
    Senior Member paul-'s Avatar
    Join Date
    Jan 2013
    Posts
    2,350
    Anyone running pCP/squeezelite having this issue, please try to update openssl.

    Open an ssh session and run "pcp-update openssl" then reboot when done. I just upgraded opensll from 1.1.0h -> 1.1.0l and that seemed to make the problem much less. Interesting to note the 1.1.0l is the last version in that series. 1.1.0 is now depreciated.

    For those with older players, turning on proxying will probably help, however your LMS server might need openssl upgraded.
    piCorePlayer a small player for the Raspberry Pi in RAM.
    Homepage: https://www.picoreplayer.org

    Please donate if you like the piCorePlayer

  6. #16
    Junior Member
    Join Date
    Dec 2015
    Location
    Hertfordshire
    Posts
    7
    Quote Originally Posted by paul- View Post
    Anyone running pCP/squeezelite having this issue, please try to update openssl.
    Thank you! I've got two pCP players, a Duet and several Booms and this problem has been going on since the beginning of the FLAC streams. I have tried most things to no avail, but upgrading openssl on the two pCP players has solved the issue for me. (My Debian server was already on the latest version).

    Again, a huge thanks to everyone involved in keeping our systems sounding great.

    Edit: Spoke too soon. It's much improved, but still re-buffers every few hours.
    Last edited by BenB; 2019-11-16 at 10:53.

  7. #17
    Senior Member
    Join Date
    May 2006
    Location
    Silicon Valley
    Posts
    434

    RP FLAC Interactive failing to stay connected...

    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?
    Last edited by Ron F.; 2019-11-11 at 12:20.
    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 > Emotiva Little Ego DAC > Senn IE 80 earbuds
    Phone: Pixel 3a Phone + BubbleUPnP + Kiwi/Material > Bluetooth > Bose SoundLink Revolve
    Server: Puget Systems Serenity + Ubuntu 18.04 + LMS 7.9.2
    Music: Personal FLAC, Radio Paradise FLAC, Qobuz, Spotify

  8. #18
    Senior Member
    Join Date
    May 2008
    Location
    Canada
    Posts
    5,109
    Quote Originally Posted by Ron F. View Post
    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

  9. #19
    Senior Member
    Join Date
    May 2006
    Location
    Silicon Valley
    Posts
    434
    Quote Originally Posted by philippe_44 View Post
    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)
    OK, but then I do not understand why this issue does not occur with the Regular FLAC stream, only the 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 > Emotiva Little Ego DAC > Senn IE 80 earbuds
    Phone: Pixel 3a Phone + BubbleUPnP + Kiwi/Material > Bluetooth > Bose SoundLink Revolve
    Server: Puget Systems Serenity + Ubuntu 18.04 + LMS 7.9.2
    Music: Personal FLAC, Radio Paradise FLAC, Qobuz, Spotify

  10. #20
    Senior Member
    Join Date
    May 2008
    Location
    Canada
    Posts
    5,109
    Quote Originally Posted by Ron F. View Post
    OK, but then I do not understand why this issue does not occur with the Regular FLAC stream, only the Interactive stream?
    I can only guess at that time that the regular stream are infinite streams, so the HTTP server might behave differently when there is no content-length.

    I also tried to think of a resume solution, but the way LMS and plugins are architectured, it seems very difficult
    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

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •