Home of the Squeezebox™ & Transporter® network music players.
Page 1 of 3 123 LastLast
Results 1 to 10 of 27
  1. #1
    Junior Member
    Join Date
    Nov 2017
    Posts
    20

    Internet radio stream setting has no effect

    Hi,

    I'm mostly streaming internet radio stations via my LMS to my AirPlay devices. Sometimes I'm facing connection issues (drops of a 2-3 seconds or the stream stops at all while the player is still in "play" mode and counting the time, which is strange). So I've started to increase the "Radio station buffer seconds" in LMS in "Advanced" -> "Network".

    Strangely this has no effect at all! All players are set to "proxied" as the streaming method. Even when I set the buffer to the max of 30 seconds for a test and I start a radio station, it starts playing after around 3-4 seconds.

    My understanding of how a buffer works is that if it's set to 30 seconds, that it'll fill up the buffer for 30 seconds before it can start playing. But regardless of the setting here, it always starts the stream after a few seconds.

    What do I overlook here? I don't want to have a 30 sec buffer, that's just a test which proves that the setting seems to have no effect at all ...?!?

    I'm running version 7.9.0

  2. #2
    Senior Member
    Join Date
    Oct 2005
    Location
    Ireland
    Posts
    15,578
    Quote Originally Posted by netmax View Post
    Hi,

    I'm mostly streaming internet radio stations via my LMS to my AirPlay devices. Sometimes I'm facing connection issues (drops of a 2-3 seconds or the stream stops at all while the player is still in "play" mode and counting the time, which is strange). So I've started to increase the "Radio station buffer seconds" in LMS in "Advanced" -> "Network".

    Strangely this has no effect at all! All players are set to "proxied" as the streaming method. Even when I set the buffer to the max of 30 seconds for a test and I start a radio station, it starts playing after around 3-4 seconds.

    My understanding of how a buffer works is that if it's set to 30 seconds, that it'll fill up the buffer for 30 seconds before it can start playing. But regardless of the setting here, it always starts the stream after a few seconds.

    What do I overlook here? I don't want to have a 30 sec buffer, that's just a test which proves that the setting seems to have no effect at all ...?!?

    I'm running version 7.9.0
    The effect of the "Radio Stream buffer" setting will depend on the player and the stream format - for example, depending on transcoding settings it can have little effect on a SB3 playing an AAC stream.

    So more details at the very least,URL of station being played ,Type of player, Version of LMSW and OS and hw platform.

  3. #3
    Junior Member
    Join Date
    Nov 2017
    Posts
    20
    Quote Originally Posted by bpa View Post
    The effect of the "Radio Stream buffer" setting will depend on the player and the stream format - for example, depending on transcoding settings it can have little effect on a SB3 playing an AAC stream.

    So more details at the very least,URL of station being played ,Type of player, Version of LMSW and OS and hw platform.
    It's 128 kBit/s AAC streams, but streaming the same as 320 kBit/s MP3 streams is even worse.

    Players are mostly AirPlay devices via AirPlay Bridge, but also SqueezePlay clients on Windows 10. Radio stations are Radiotunes or Digitally imported (can't disclose URL's as they contain my premium subscription key). LMServer is 7.9.0, I've updated it to the nightly 7.9.1 but can't see the stream delays here as well. OS is Ubuntu server 16.04 LTS, running on VMWare ESXi on a Dell R710 server (given 2GB and 4 L5640 cores which is more than enough).

    Streaming directly from my iPhone to my airplay devices via the Radiotunes/DI app works without interruption for hours, but that uses more buffer (the time from "play" to working output is higher here). So I'm pretty sure that I need a few seconds more buffering, but even with "2 seconds" and "30 seconds" set in the LMS server there is no different delay from starting the player until the music starts - so I assume something's not really working with the buffering.

  4. #4
    Junior Member
    Join Date
    Nov 2017
    Posts
    20
    My initial post worked directly, my answer has been put into moderation queue ... I have a feeling this forum software is somehow buggy
    I'll wait if it appears here before I retype anything again ...

  5. #5
    Junior Member
    Join Date
    Nov 2017
    Posts
    20
    @bpa ... just thinking about what you said. Why has the stream format, transcoding etc. an effect to the stream buffer?
    In my understanding the stream buffer should be the first thing where the incoming stream packets from the netif run into. They are buffered for the amount of seconds in a FIFO way and then passed to the next LMS "module" for further processing (transcoding, routing to the players ...)

    Basically your words tell me that it's working different in LMS. I'd like to understand it to fix the issue, i.e. if some configuration changes are needed in a deeper place than the settings web interface. It'll be awesome if you can point me to some docs which may help me here. Currently I've a drop every 20-30 minutes which lowers the WAF dramatically ;-)

  6. #6
    Senior Member
    Join Date
    Oct 2005
    Location
    Ireland
    Posts
    15,578
    Quote Originally Posted by netmax View Post
    @bpa ... just thinking about what you said. Why has the stream format, transcoding etc. an effect to the stream buffer?
    In my understanding the stream buffer should be the first thing where the incoming stream packets from the netif run into. They are buffered for the amount of seconds in a FIFO way and then passed to the next LMS "module" for further processing (transcoding, routing to the players ...)

    Basically your words tell me that it's working different in LMS. I'd like to understand it to fix the issue, i.e. if some configuration changes are needed in a deeper place than the settings web interface. It'll be awesome if you can point me to some docs which may help me here. Currently I've a drop every 20-30 minutes which lowers the WAF dramatically ;-)
    You are not using normal SB players and as such normal LMS rules & settings do not apply in the same way.

    The Airplay bridge converts all streams into a consistent format and I think has its own proxy system -I think your problem require tuning the airplay bridge plugin. Post your problem on the airplay bridge plugin thread.

    I'm guessing you're using http://forums.slimdevices.com/showth...(squeeze2raop)

    edit:

    Squeezeplay players are normal SB - if you want to troubleshoot these players alone and unsynced - indicate if you want to continue.
    Last edited by bpa; 2017-11-19 at 14:14.

  7. #7
    Senior Member
    Join Date
    May 2008
    Location
    Canada
    Posts
    3,537
    as @bpa said, I would recommend trying on SB at a time, then 2 SB synced, then 1 AirPlay, then 2 Airplay synced to try to isolate the issue. Do all players stop or only AirPlay?

    You can also post the AirPlay bridge log so I can see what's happening there. The "pause" can have many different causes, including some synchronization problems. In such case, LMS pauses all the streams and send another synchronized start, all that happens quickly. You light also have local network throughput issues.

    Re buffering, it's not because you want to buffer more that the stream should start later. All these stations have their own buffer/liev shift and when a client starts, they can send a burst of data so that the client has enough buffered. That's an assumption, but LMS could easily get what it wants (2 to 30s, depending what you have set) in a burst that lasts 1s (e.g.) and send the start command to players right after that
    Last edited by philippe_44; 2017-11-19 at 14:32.
    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

  8. #8
    Junior Member
    Join Date
    Nov 2017
    Posts
    20
    Hi,

    thank you for your inputs!

    I do not use any player synchronized, they're all stand alone. I need to get more information especially in compare between the SB player and the AirPlay devices. I've listened via SB player in the office on Friday, but I won't count this as that's running really via internet and VPN - there's another point which might cause lags. So I need to run the SB here locally on my W10 machine for some time and see if this drops. iPeng did also drop, but that's also a 3rd party Player which runs via WiFi in addition (even it's a good managed WiFi).

    At home all is wired, included the AirPlay devices. Network is 1GBit/s using proper manageable switches and a professional router (Ubiquiti EdgeRouter Pro). The internet feed to the LMS VM runs via my priority VLAN which runs VoIP, TV and media streams prioritized. I'll enable the AirBridge log and see what this shows, anything else which would be useful?

    All these stations have their own buffer/liev shift and when a client starts, they can send a burst of data so that the client has enough buffered. That's an assumption, but LMS could easily get what it wants (2 to 30s, depending what you have set) in a burst that lasts 1s (e.g.) and send the start command to players right after that
    How does this work? When the stream is stopped, I don't see any stream traffic to LMS in iftop ... so the stream from the radio station is also stopped. When I start the stream and the radio station delivers a 128 kBit/s AAC stream, how should it "know" that it can send faster to fill up a 30s buffer in three seconds?

    I'll try to collect more information and will come back here.

  9. #9
    Junior Member
    Join Date
    Nov 2017
    Posts
    20
    OK, I've read a bit in the Shoutcast spec and about prebuffering ... so it's possible to fill buffers fast

    Seems I need to get Wireshark in place to have a look what's going on there ...

    @Philippe: How's the GGMM E5 ... I've seen in your sig. Is it worth buying it to carry the music into the garden next spring via AirPlay bridge?
    Last edited by netmax; 2017-11-19 at 16:19.

  10. #10
    Senior Member
    Join Date
    Oct 2005
    Location
    Ireland
    Posts
    15,578
    Quote Originally Posted by netmax View Post
    @bpa ... just thinking about what you said. Why has the stream format, transcoding etc. an effect to the stream buffer?
    In my understanding the stream buffer should be the first thing where the incoming stream packets from the netif run into. They are buffered for the amount of seconds in a FIFO way and then passed to the next LMS "module" for further processing (transcoding, routing to the players ...)
    By way of background to help understand some of the process.

    1. The player "Proxied" setting applies to stream where LMS handles the "Normal" http streams which can be played natovely by a player. An SB2 can play HTTP/MP3 directly but not HTTP/AAC. Squeezeplay can play HTTP/MP3 & HTTP/AAC natively. When a stream can be played natively - the stream goes directly from station to player bypassing LMS. LMS but only if the player is not synced. Whena player is synced or "proxied" then stream is handled by LMS first and then passed to player without processing. Proxied setting is useful for "lumpy" network streams often due to network issues between user network connection and station.

    2. Some stream cannot be played by a player directly such as DASH or HLS (aka m3u8) these are often processed by a plugin which does buffering and so proxied setting has no effect. Some of these plugin may also override/ignore the "Radio Station Buffer seconds" setting"

    3. The "Radio Statio Buffer seconds" setting is an estimation at how much audio "rtime" should be stored in player before playing starts. The player actually requires a number in bytes so an estimate has to be made converting seconds to bytes and this depends on the incoming format and whether stream data such as bit rate is available to estimation routine.

    4. If the incoming stream is "Live" then it is not possible to fill buffers quicker than realtime which resultsin delay in starting program playback. Whereas a recorded program can often be downloaded and buffers can be filled in much less time than it takes to play so no appreciable delay before audio starts.
    Last edited by bpa; 2017-11-19 at 16:24.

Posting Permissions

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