mbg wrote: > I did see some posts about that, but how does it fit with: > > > > > Rebuffering only occurs on Boom and not Radio (both using the same > server)> > > > > > Using 'ffmpeg' to handle HLS eliminates the problem> >
About Windoews I am only going on what other users have posted - I haven't dealt with WIndows. > For the 2nd point, if it was a DNS caching issue, wouldn't you expect > both HLS implementations (iPlayer, ffmpeg) to have the same problem? I said it is hard to pin down. LMS has its own DNS lookup and caching which is different code to ffmpeg's so differences would not be unusual. The problem with HLS is that different segments are on different servers each one requires a DNS lookup. If the read request gets delayed - LMS buffer gets depleted perhaps just by 0.1sec at a time. LMS is using a single core and its own version of multithreading - a "select" loop (i.e. LMS looks at all I/O request that are ready and picks one) - however I don't know whether LMS is treating DNS request differently to others such as audio or slimproto. If a processing task such as plugin hogs processing and doesn't let LMS back to "select" loop - I/O are not handled. ffmpeg is properly multihreaded (i.e. if running on a mulitcore CPU there are more scheduling options) and ffmpeg could makes overlapped HLS network requests for audio so there is more leeway to recover from delays. ------------------------------------------------------------------------ bpa's Profile: http://forums.slimdevices.com/member.php?userid=1806 View this thread: http://forums.slimdevices.com/showthread.php?t=103435 _______________________________________________ plugins mailing list plugins@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/plugins
