mrmichaelwright wrote: > Ok so I'm back :D > > I've been testing both my duet and boom with the only 320 kbps aac > stream I can find (Radio Paradise http://37.130.228.60:8014) > > Both work fine, no re-buffering or pauses. It is trans-coded by the > server (320kbps CBR (Converted to 705kbps FLAC)) > > If i switch to a BBC DASH stream, the pauses and re-buffering are back, > also trans-coded to FLAC. > > This is NOT the case on my SB Touch or Radio players. > > This made me take a look at the performance of my server during > trans-coding. The re-buffering appears to appear along with spikes in > CPU activity, these spikes are just after the stream re-starts and show > as about 25-50% CPU usage. It could be that the spikes are the cause of > or a result of the pauses (i'm aware the timing on Windows Resource > Monitor won't be accurate enough to say which is the case), i think it > more likely that they are as a result of the stream re-starting as LMS > seems not to glitch during a 100% CPU spike from other system services. > > Bare in mind that at least 50% of my library is ALAC and the server > trans-codes this flawlessly at higher bitrates and copes with doing this > for several players streaming different local content. > > If I switch back to the Radio Paradise stream I get a perfectly flat > constant CPU usage during transcription. If i switch to one of my SB > Touch players and a BBC DASH stream the CPU usage is again flat. > > I don't know if any of this is relevant but taking into account what has > been said above it does seem that something either LMS or BBC side is > making BBC DASH streams far more un-reliable than other similar bit-rate > streams specifically on players running older type firmware (57/77) > > The problem is definitely worse with Radio 4 > (dash://a.files.bbci.co.uk/media/live/manifesto/audio/simulcast/dash/uk/dash_full/ak/bbc_radio_fourfm.mpd) > than it is with Radio 6 > > And in case it is relevant I am on BT infinity with a connection that > consistently tests at 70+ Mbps with 30ms pings and in a low-traffic > rural area (thankyou Digital Scotland :-) )
I think the much larger internal buffer of Radio and Touch means delays which happen during BBCiPLayer playback have less effect than with SB3 player which have a smaller buffer. My test with DASH reference player compared to BBCiPlayer was interesting. Both stream played OK no errors all day long from about 9:30am until 4.00pm then the BBCiplayer stream started getting errors and long packet delays while there was only one small hiccough on the DASH reference player. Since 4:00pm there have been more and more bursts of errors on BBCiPlayer. So time of day is one part fo the issue whether it is a BBC, CDN or my ISP - I can't tell. Also there is probably some issue with LMS and how it process http GETs (probably DNS part) that is different to the Chrome and this needs to be checked. ------------------------------------------------------------------------ bpa's Profile: http://forums.slimdevices.com/member.php?userid=1806 View this thread: http://forums.slimdevices.com/showthread.php?t=104672 _______________________________________________ plugins mailing list [email protected] http://lists.slimdevices.com/mailman/listinfo/plugins
