ChaoticMike wrote: > I stopped the Squeezebox server (SBS) process, emptied the logs and > restarted, followed by a connection to the R4 feed via the BBC iPlayer > app. Dropouts continue, but there is nothing relevant being recorded in > the SBS' error log. Can you do as I ask ? sometimes it is the messages that *aren't* there that provide a clue to the problem. After I see a baseline I can then ask for increased logging.
How do you select the R4 ? from BBCiPlayer mneu or a Favorite ? If it is a Favorite -please paste the URL used. After you press play - how long before rebufferring occurs" When you get rebuffering - do you get the "rebuffering" message on the display ? If you do - on Boom - how long it take to "recover" - when you see the display showing the increased percentage fullness of the buffer ? The rebufferring only happens on "Live " or also on "Listen Again" If you play a http/AAC stream suchg as SomFM (http://somafm.com/illstreet130.pls ) in the same way as R4 - this will stress the network and LMS with same transcoding as R4 > Are there any flags I can set anywhere that could temporarily turn up > the logging on the SBS? Lots - too many so we need to be careful and need to see what is in the normal log first before adding other stuff. > My WAN supply is Virgin media broadband, which is supposed to be a swift > and wide pipe. The LAN is the Virgin box providing wireless in some > part of the house, augmented by powerline extenders. I know the > Raspberry Pi 3 that hosts SBS is directly attached to the wireless > router via Cat-5. It's not always easy to tell, but I'm pretty sure the > Boom is on a wireless extended segment, as are two other Duet radios. > The Joggler is also wired directly onto the wireless router, a further > Duet is on a second wireless extender segment. > Extenders - wireless and powerline. These can cause trouble. However if you get rebuffering on the display and if the problem only affects "Live" and doesn't affect other AAC streams, the local network is unlikely to be the reason > As far as the various slim protocols are concerned, is the network > assumed to be present and irrelevant (i.e. devices are expected to be > able to reach the SBS process, and it doesn't try any network management > tricks itself? Slimproto is old so it only does basic network stuff - no priortising of data . No network management tricks - just a good network capable of delivering about 700kbps/sec per player consistently - however a display of "rebufferring" is more often a soruce issues rather than a local LAN. However your network may have issues. For example many wireless extenders halves bandwidth ! Powerline is a shared medium so that multiple devices on the Powerline active at the same time reduces the bandwidth by a factor of the number of devices. > Yesterday, for a short period, Spotty/Spotify was playing up with > dropouts, but that seems to have stopped. I'm listening to Spotify > right now, and its find. If I swap back to Radio 4, I'm back in a world > of buffering. Spotify has its own issues and helper apps. Not a good test. Somafm stream is a better cleaner test AAC source. > Any ideas on turning up the wick on network monitoring, or other > investigations I can carry out? Plenty of things can be done and this could be very tedious as each step has to designed to eliminate or narrow down a cause. But first, the baseline has to be understood so that variations from the baseline can be checked. You didn't answer the question about the time on the LMS server ? Is it correct (OK within a few secs - not fast or slow and correct timezone) ? Is it NTP synced ? ------------------------------------------------------------------------ bpa's Profile: http://forums.slimdevices.com/member.php?userid=1806 View this thread: http://forums.slimdevices.com/showthread.php?t=109826 _______________________________________________ plugins mailing list [email protected] http://lists.slimdevices.com/mailman/listinfo/plugins
