sota wrote: > I mainly noticed it on listen live. I have changed "Seconds to delay > start of live stream" to 2 min as you suggested, and this made a big > improvement. However, it still rebuffers every few minutes. This is what > I see in the logs: > > [16-11-03 08:21:20.0867] Slim::Networking::IO::Select::__ANON__ (131) > Error: Select task failed calling > Slim::Web::HTTP::sendStreamingResponse: illegal file descriptor or > filehandle (either no attached file descriptor or illegal value): at > /<C:\PROGRA~2\SQUEEZ~1\server\SqueezeSvr.exe>Slim/Networking/IO/Select.pm > line 134.; fh=Slim::Web::HTTP::ClientConn=GLOB(0x6a7139c) > > [16-11-03 08:22:24.5903] Plugins::BBCiPlayer::DASH::__ANON__ (694) > status 200 Long chunk fetch time 3186 ms
What sort of "improvement" happened - How often does rebuffering happen ? Is rebuffering event less frequent ?, Are there fewer rebuffering evenet, Is stream fast to start, Is there gap at start audio , quiet and then audio again ?- without better characterisation of the problem it cannot be understood. Does it ever occur on Listen Again ? What is the "Live stream preference" Setting ? When "Live Stream preference" is set to HLS - do you get the same problem ? What security s/w are you using ? Are the socketwrapper and LMS server executable exclusions and/or makred as trustworthy. Your problem could be a combination of Boom wifi issues and the Windows transcoding issues so there is a need to checkout other AAC streams and whether Radio shows same problem if transcoding. Can you run the following tests 1. Play an AAC stream on Boom such as http://www.somafm.com/illstreet32.pls - does it play without rebuffering 2. Disable "native" AAC under WebUI/Setting/ Advanced/Filetypes, click Apply and then play BBC live streams on Radio - do you get rebuffering ? 3. On Boom using Settings/Information/Network Test what is highest throughput you can get with 100% - each test should last at least 3 mins. Start testing at 500k . "Select task failed" occur when a program stops or a packet is slow (> 20 secs) in replying . These message do not indicate anyhting "bad" Single Long chunk time message is OK as it is only 3 secs and not enough - if you get multiple then problem is at the BBC. Long packet time (> 800ms) happen at least once a day especially at busy time typically between 4.00pm and 7.00pm but also less frequent early morning 7.00am-9.00am - this is a "BBC" issue. >From other user reports of 1.4.9 - rebuffering has been very common on Windows systems. One possible cause with using HTTP 1.0 and this is what 1.5.x fixes. Clearing up the HTTP/1.0 vs HTTP/1.1 issue with 1.5.x showed up another issue relating to transcoding using socketwrapper which only happens on Windows. 1.5.1 address this socketwrapper issue. It is possible there is yet another issue and with enough information hope to reproduce on my systems. For comparison. my setup includes: ISP link is Eir 10/1. Local LAN - test machine are connected to router through Powerline and Wifi and switches - so lots of network stuff with potential for problems. I can reproduce similar problem on old laptop running XP 1.5Mhz single core 2Gb ram - the "socketwrapper" rebuffering problem goes away using 1.5.1 with delay at 2 min for 48k and 1 min for 96k No problems on a newer Win7 laptop with 8Gb Ram and core i5 which had some problems on 1.4.9 due to HTTP/1.0 No problem on an Ubuntu system. core i5 and 16Gb ram. Players Boom, receiver, Radio and Touch. I get rebuffer issues only Boom occassionaly regardless of source but will be most noticeable on internet streams. ------------------------------------------------------------------------ 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
