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) ------------------------------------------------------------------------ mrmichaelwright's Profile: http://forums.slimdevices.com/member.php?userid=65105 View this thread: http://forums.slimdevices.com/showthread.php?t=104672 _______________________________________________ plugins mailing list [email protected] http://lists.slimdevices.com/mailman/listinfo/plugins
