Bugzilla – Bug 11911
Ip3k starting to play randomly with packet loss over 2-3%
Last modified: 2009-11-02 09:08:52 UTC
Ticket # 090414-000485 Airlink 101 MIMO XR Wireless Router firmware version v1.0.22 128-bit WEP Issue occurs when connected to SqueezeCenter and SqueezeNetwork Squeezebox Duet Receiver - 3 SB receivers - happens randomly - even when just one receiver is being used - The only way the customer can prevent this from happening is to unplug his receivers Symptom: Customer states that his receiver(s) will start playing randomly in the middle of the night (or at random times). Per QA, had run the following command to try to get packet loss information. ping www.squeezenetwork.com -f -t Ran for about 1/2 hour. After about 1/2 hour, hold down the "Control" button, and hit the "C" key on your keyboard to end the ping. The results are as below (the customer ran the test twice) One result was: PAckets Setn = 1651; Received = 1651; Lost = 0 (0% loss) Approx. Round trip time Min = 32ms; max = 260ms; avg=34ms Second result Packets Sent = 831; Received = 699; Lost = 132 (15% loss) Average round trip time Min=32ms; max=58ms; avg = 32ms Spoke with QA, and was advised to file this bug. Thanks, LaRon
Alan: Isn't that something you already looked?
Well it sounds like it could be the same as bug 11227. Once the packet loss goes much above 5% then the network is practically unusable for this kind of application.
LaRon, We need to know exactly what version this was reported against. Can you confirm that the user had paused his player, either via Pause or via Power-Off with the power-off-resume preference set to *-ResumeAtPowerOn? Alan.
To all- Please accept my apology for not responding to the earlier commentary on this bug. LaRon gave me the instructions to add myself to this bug thread but I never followed through, creating a user ID and such. I have now done so (obviously). As to the questions below, here's the story. Squeezecenter Version: 7.3.3 - 27044. Three receivers, all firmware 62. Controller 7.3 r6038. The behavior that I reported months ago happened when I would pause a song (which is the only way I know to stop it), and then dock the controller in the cradle, leaving all receivers on. I was repeatedly unhappy to experience that it would randomly just start up and begin playing the music (it happened in the middle of the night, a number of times). Inasmuch as it was explained as a bug, the only workaround I could figure out was to turn the receivers off and then the controller (although I generally leave Squeezecenter running on my PC so that it will update playlists and my library, etc.). While annoying and disappointing, that's how I've lived for months, but today I experienced something altogether different. After using the system last night I did as normal. I turned off the receivers, then turned off the controller. But today I noticed that music was playing. Somehow the software had turned on the receiver and just started playing music on its own. I turned on the controller, turned of the receiver, then the controller, and yet time and again it just started playing again. So I turned off Squeezecenter and called your support group at the end of the day. Hopefully I've explained this behaviour clearly. Feel free to ask questions if I can clarify anything further, and I look forward to any observations or guidance you can provide. Having music playing randomly is pretty much a big bummer, you know? Thank you. Dave
Nobody else has reported this issue. Assigning to QA to investigate. La Ron, I'll stop by and chat with you about this bug.
*** Bug 14188 has been marked as a duplicate of this bug. ***
*** Bug 10925 has been marked as a duplicate of this bug. ***
(In reply to comment #2) > Well it sounds like it could be the same as bug 11227. Once the packet loss > goes much above 5% then the network is practically unusable for this kind of > application. Do we have any sort of requirement in terms of packet loss? At what point do we not expect this to work. I could introduce packet loss on a network with the WAN EMU tool Wise Matt put together for QA, but what will I prove?
A properly functioning network should have packet-loss rates below 1%. I would consider it unreasonable to expect a streaming application to work properly with rates much higher than that. At 5% I would not expect very much to work at all.