Bugzilla – Bug 8305
Some internet streams fail on Boom but work on SB2
Last modified: 2012-02-27 17:33:32 UTC
Certain internet streams exhibit regular (every 5-10 minutes) pausing and rebufferring when played on the Boom. The same streams play flawlessly on the SB2, so there appears to be a Boom-specific issue. Also, the same streams will play fine on both the Boom and the SB2 if the players are synced. So far, I've only seen the problem with the following 2 streams: http://kpcc.streamguys.com/listen.pls http://media.kcrw.com/live/kcrwlive.pls The problem is 100% reproducible with these streams. I haven't tested that many, so there are probably others. When testing, it's easy to see if a given stream has a problem without waiting for it to fail by watching the decode buffer fullness with the screensaver and observing whether it declines.
I think this really needs to go to felix or Sean. I don't know anything about how that part of the code works. I don't suspect this is a hardware issue. -CAleb
Wired or wireless? Is this just a range problem or do you think something else is going on?
(In reply to comment #2) > Wired or wireless? > > Is this just a range problem or do you think something else is going on? > I have tested this pretty extensively using both wired and wireless and the symptoms I describe are 100% reproducible on both. It's not a range issue.
Adding QA. Perhaps they can help reproduce the problem, and add it to their regression tests if its reproducible. -Caleb
Please let me know what else I can do to help. I know nothing about this part of the code, so I'm not even sure what logging would be most helpful. As I said, this is 100% reproducible for me. I suppose it's possible that it's a network issue on my side so let me know if anyone has tried and/or managed to reproduce it.
Thanks for the help. If we can reproduce it in-house, that would be best, because then (if necessary) we can set up virtual servers that can produce the problematic streams so we don't have to rely on outside stream behavior. If we can't reproduce it in-house, we'll need ... something. maybe packet captures & logs.
Fletch, do you get the same behavior connecting to SqueezeNetwork directly as well as with SqueezeCenter? Just curious if it makes a difference.
(In reply to comment #7) > Fletch, do you get the same behavior connecting to SqueezeNetwork directly as > well as with SqueezeCenter? Just curious if it makes a difference. > Yes, the symptoms seem exactly the same. Note that the NP screensaver doesn't seem to display buffer fullness on SN, so it's a little easier to test on SC instead.
Steven to try with Transporter on Felix's suggestion to try to see if it's a memory issue.
I just noticed something strange about this that may provide a clue... If I do the following: - Start one of the problematic streams while Boom and SB2 are synced - Listen for a few seconds while the buffers fill - Drop the SB2 from the sync group and turn it off ...The Boom will now continue to play the stream with none of the rebuffering problems. Boom will still fail if I start it alone (unsynced). HTH
FYI, the same failure occurs on PQP3 (the original bug report was based on a PQP2). Both currently at FW12. Anything else I can do to help with this?
One more weird data point on this: Now that I have a 2nd Boom, I confirmed that they both exhibit this problem as per comment 11. But, if I start them synced (without also syncing the SB2), the stream plays fine on both.
FYI, this problem is still reproducible with FW 18.
FYI, this problem is still reproducible with Alan's new-streaming branch.
I have never been able to reproduce this issue. My most recent attempts to reproduce was using Boom PQP3 units with FW 23. I played both of the suggested steams without issue for hours. This was both through SqueezeCenter and connected directly to boom.squeezenetwork.com. Is it possible that it is something particular with Fletch's internet connection?
(In reply to comment #15) > I have never been able to reproduce this issue. > > My most recent attempts to reproduce was using Boom PQP3 units with FW 23. I > played both of the suggested steams without issue for hours. This was both > through SqueezeCenter and connected directly to boom.squeezenetwork.com. > > Is it possible that it is something particular with Fletch's internet > connection? > Ugh. I wish I had known this sooner. There is nothing weird about my internet connection. It's a normal DSL 3M/768K static IP connection via Verizon. Because of the fact that the above described "sync tricks" work around the problem, I figured it was not related to my ISP. I may have time tomorrow to take my Boom and try this on a different internet connection. I suppose it's also possible that this is something weird with my router (I run IPCOP). FWIW, I just tested this again earlier today to make sure the problem still persists with FW22 and it is still 100% reproducible. Steven, do you have the "show buffer fullness" NP screensaver active when you're testing? If so, can you describe what it does over the first 15 or 30 seconds? For me, it's pretty easy to see that the amount of data in the decode buffer is decreasing long before it actually needs to rebuffer.
Fletch, one thing I wanted to note was that by enabling syncing you are also effectively enabling proxied streaming. Proxied streaming can also be enabled independently of syncing by navigating to settings -> player -> audio for your boom and selecting "Proxied Streaming" for the "MP3 Streaming Method" option. You might want to check if this option is enabled for your SB2. If this is the case it would explain why you are seeing different performance on your boom versus your SB2. If not this option will at least let you compare performance issues with your boom without syncing.
(In reply to comment #17) > Fletch, one thing I wanted to note was that by enabling syncing you are also > effectively enabling proxied streaming. Interesting. I never thought about that but I guess it's obvious now that you point it out. Anyway, I'm pretty sure I've never used proxied streaming on any of my players, but I just tested as follows with unsynced players using todays SC: Using the KPCC stream mentioned above: SB2/Direct streaming - OK SB2/Proxied streaming - OK Boom/Proxied streaming - OK Boom/Direct streaming - fails as described in this bug report Is there any other obscure player setting that could be enabling proxied streaming on my SB2 as a side effect? I guess this at least provides a usable workaround to stream to an unsynced Boom when connected to SC. Not sure if there's a similar workaround when connected to SN.
(In reply to comment #18) > Is there any other obscure player setting that could be enabling proxied > streaming on my SB2 as a side effect? Not that I know of but I suppose it could happen. You might want to try setting all player logging such as player.source, player.streaming, player.streaming.direct and player.streaming.remote to debug and see what the log says. It should show if it is using proxied streaming or not.
I can try that later if necessary, but the following test probably rules that out: Using the same KPCC stream via RadioTime: SB2 on SN - OK Boom on SN - fails as described above
(In reply to comment #20) > I can try that later if necessary, but the following test probably rules that > out: > > Using the same KPCC stream via RadioTime: > SB2 on SN - OK > Boom on SN - fails as described above If you are using your local SqueezeCenter going through RadioTime should not make a difference since all RadioTime does is provide a directory listing of stations and does not touch the actual streams. If you switched over to SqueezeNetwork however that might be difference.
Sorry I wasn't clear. Comment 20 refers to both players connected directly to SN. I was suggesting that the problem is not related to any SC setting based on these results. I agree that the reference to RadioTime is irrelevant.
I can't reproduce this either.
(In reply to comment #23) > I can't reproduce this either. > Hrm. Which stream did you try? For me it's 100% reproducible with the one from KPCC (either using the URL above or via RadioTime). How long did you wait for the first "rebuffering"? It can take close to 30 min for the first failure and will then fail every 10 mins or so. Did you try it with the "show buffer fullness" option turned on? Within 20 seconds or so, you can easily see whether the decode buffer is starting get empty. I should have time later today to try this at a different location thereby eliminating my ISP and my router from the equation.
I tried KPCC for about 10 minutes and KCRW for 30, with buffer fullness display on. Buffer was rock solid on both streams the whole time: around 24/10 for KPCC and 6/10 for KCRW. I'll try KPCC again for longer.
(In reply to comment #25) > I tried KPCC for about 10 minutes and KCRW for 30, with buffer fullness display > on. Buffer was rock solid on both streams the whole time: around 24/10 for > KPCC and 6/10 for KCRW. > > I'll try KPCC again for longer. > Weird. On both of my Booms, I see the KPCC decode buffer drop below 20 within 30 secs or so.
I see pretty much the same numbers that Andy reported in comment #25. This was even after about 4 hours of playing both streams.
1 hour into KPCC, no problems at all.
<sigh> OK, I resisted but I'm now testing at another location with my PQP3 Boom. I think it's road runner cable (not sure what speed). Anyway, I can't reproduce the issue here with the KPCC stream via SN. <sigh> again... Reducing severity - feel free to remove this from the 7.2 queue. There's still something different between Boom and SB2 though. I'll do some testing tomorrow to try to narrow it down between my router and my ISP. Sorry for the false alarm.
So, I can reproduce this perfectly with my lousy setup with VMware and my network. SB3 plays KPCC flawlessly, and Boom TIMES OUT. Sometimes it will play a few seconds first, then fail.
How would a slow VMWare affect anything when direct streaming though? Can you give more instructions on how to reproduce?
My SC server is not slow and I can reproduce this at home on both SC and SN. Caleb and I may be seeing different things...
I think it's very unlikely that we're seeing different things. Mine is more severe than yours, as it only plays for 10-20 seconds at best. SB3 works just dandy. I'm not sure that the slowness of the machine is the problem, but rather, the slowsness of the network. But I don't know yet. Now that we can reproduce it in-house, it should be diagnosable. Andy, I don't know how to reproduce it yet. Other than connecting on my little subnet. I'll post when I know more.
OK, I've figured this out and it's 100% due to my network. My home router/firewall (IPCop based) is set up to run Squid in a transparent proxy configuration. A long time ago (to solve a similar but different problem) I tweaked my config to allow my SB2s to bypass Squid. I had forgotten about that until this morning. If I disable Squid, the KPCC stream plays fine on both SB2 and Boom. I have no idea why Squid would cause this or why it only impacts certain streams. I should note that I can play the KPCC stream on a desktop player that goes through the proxy and it works fine, so the problem is specific to SB players. This should at least be documented somewhere. I guess I'll leave this open for now in case Caleb wants to use it to track his issue, but it now seems that he's seeing something different. Thanks for all the help.
Thanks for sharing this information and spending all the time to investigate this issue.
Fletch, I am so glad that you figured this out! Thank you so much for the time and effort. Caleb, are you still able to reproduce?
Odd, when I came in this morning, the Boom worked and SB didn't. The I reset the networking and both worked again. I'll need to look a little more...
Caleb, I am going to close this one for now. Please reopen and add additional comments if you experience the issue again, thanks.
Closing resolved bugs - if you feel this bug still exists please first re-test with the latest SW/FW version. If you are able to reproduce then feel free to reopen and attach new logs / steps to reproduce.