Bugzilla – Bug 11660
SqueezeBox Receiver constantly pauses playback
Last modified: 2009-09-08 09:22:02 UTC
Hi Support, I have a setup with 2 Duets and 2 Booms. Server software runs on a Windows HomeServer SP2 on a Fujitsu-Siemens Home Server 1900. Right now, I am running SqueezeCenter 7.3.3.25698 which is beta, but my problem has existed for a long time and with several versions, including 7.2.2. I general, I have been very satisfied with the whole concept and the sound quality. Problem: Receivers constantly pauses playback while I play music on them - both Internet radio and FLAC files from the server. In general it seems to get a little worse when I run 2 Receivers synchronized, but the problem is also there, when I run them solo and 1 Receiver + 1 Boom synchronized. ----------- I have had problems with sync in several rounds. A month after I got it, I had to replace my Wireless router from a Linksys WRT54GR to a Netgear WGR614, which more or less solved all my initial problems. Next, I couldn't get my Booms to play Internet Radio - it made them crash with power off/on as the only medicine. Your bug id is 10651. My own conclusion was that some (legitimate) ini settings from way back before I got the Booms made them Crash. My current sync problem is so annoying that I am on the the edge to swap the whole setup for a Sonos or Apple setup - so this is my last attempt to solve this. ----------- I have switched a lot of the logging to debug mode and the resulting log file is attached. These are the logging settings: Switched to "Debug": (control.queries) - Control Query Logging (Advanced) (control.stdio) - Standard I/O Command Logging (Advanced) (formats.audio) - File Metadata & Audio Parsing Information (network.asyncdns) - Asynchronous DNS Logging (network.asynchttp) - Asynchronous Remote HTTP Request Information (network.cometd) - Cometd protocol logging (network.http) - Internal HTTP Server Logging (network.jsonrpc) - JSON-RPC API Logging (network.mdns) - Multicast DNS / Bonjour (network.protocol) - All Player Protocol Logging (network.protocol.slimp3) - SliMP3 Protocol (network.protocol.slimproto) - SlimProto (Squeezebox / Transporter) Protocol (network.squeezenetwork) - SqueezeNetwork Logging (network.upnp) - UPnP Server & Device Information (Rhapsody) (player.source) - Player Source Audio & Conversion Logging (player.streaming) - All Player Streaming Logging (player.streaming.direct) - Player Direct Streaming Logging (player.streaming.remote) - Player Remote Streaming Logging (player.sync) - Multi-Player Synchronization Logging (server.memory) - Server Memory Usage (Advanced) This was in "Fatal": (control.command) - Internal Command Execution Logging (Advanced) ( - I don't know if that means anything) ----------- I really hope that you can solve this. Best regards, Morten Schmidt Denmark
Created attachment 5050 [details] Zipped server.log, containing debug messages for sync problems
I believe we probably have the FLAC case covered by another bug (if it is the same), but what about the Internet radio issue?
Mort: did you installed the Windows Home Server version of SC, or the normal Windows XP version? Also, if you do not have player sync enabled, do the same problems happen?
(In reply to comment #3) > Mort: did you installed the Windows Home Server version of SC, or the normal > Windows XP version? > > Also, if you do not have player sync enabled, do the same problems happen? Yes, it happens with and without sync. And both on WHS and XP versions. I have another information to add: I have now unplugged the two Receivers and moved my Booms to living room + kitchen. The two Booms run flawlessly with and without sync. I have not had a single hickup in two days, except for one short mute, when a Controller that is still attached updated its (own) software.
Thank you for the full logfile. The log does not appear to show synchronized play, although I suppose that could be part of the problem. You mention that you have the 'pausing' problem even without sync, which this log seems to indicate. It show the player with MAC address 00:04:20:16:22:95 constantly suffering output-buffer underruns. When this happens, SC pauses the player and trys to refill its buffer with about 5s seconds of audio. This appears to take between 6 and 9 seconds, which is not a good sign as it indicates that transfers to the player are happening slower than real-time (from an audio playback perspective). Once the buffer has been filled, playback is resumed, but the player is unable to keep its buffer filled sufficiently quickly and withn 20-30s runs out of data again, and the cycle repeats. I know that you have already looked at network issues, but this certainly points to a problem with the network. It is also possible, although unlikely, that the system running SC is overloaded. The log also shows player with MAC address 00:04:20:1e:93:28 paused 26s into a track. I presume that his is unrelated.
(In reply to comment #5) > Thank you for the full logfile. > > The log does not appear to show synchronized play, although I suppose that > could be part of the problem. You mention that you have the 'pausing' problem > even without sync, which this log seems to indicate. > > It show the player with MAC address 00:04:20:16:22:95 constantly suffering > output-buffer underruns. When this happens, SC pauses the player and trys to > refill its buffer with about 5s seconds of audio. This appears to take between > 6 and 9 seconds, which is not a good sign as it indicates that transfers to the > player are happening slower than real-time (from an audio playback > perspective). Once the buffer has been filled, playback is resumed, but the > player is unable to keep its buffer filled sufficiently quickly and withn > 20-30s runs out of data again, and the cycle repeats. > > I know that you have already looked at network issues, but this certainly > points to a problem with the network. It is also possible, although unlikely, > that the system running SC is overloaded. > > The log also shows player with MAC address 00:04:20:1e:93:28 paused 26s into a > track. I presume that his is unrelated. Well, you must be right, when you say that the log doesn't show synchronized play. I was so thrilled that I managed to get one of the worst periods, I have witnessed, "on tape". Do you need me to document this further? As I mentioned in #4, my two Booms now have taking over the jobs of the Receivers. What I didn't mention, is that they are placed in the exact same spots. Until now, I have not had a single dropout! That should sort of prove that the network and server are generally in a good shape. The Booms right now both report 84% signal strength. The Receivers generally reported 45-55%, when placed in the exact same spots. For a period of a couple of weeks, I also wired the Receivers as an attempt to rule out the wireless network. This did not change anything. When setting that up, I tried several things to disable wireless reception on the Receivers to make sure that they were running over the cable. I couldn't figure out how, but left the cables in (in both of them). I couldn't see anything about this in SC and eventually concluded that they ignored the cables. And the cables didn't improve on all the errors at all. My personal theory is that the radio part of the Receivers is not as good as the one in the Booms, and hence I have been thinking of trying two SB3s instead, out of an assumption that SB3 share radio design with the Boom, just as they share display - can you enlighten me here? I know that this is more or less qualified guess-work from my side - is there anything more I can log/debug to clarify the matter?
(In reply to comment #6) > Well, you must be right, when you say that the log doesn't show synchronized > play. I was so thrilled that I managed to get one of the worst periods, I have > witnessed, "on tape". Do you need me to document this further? Was it supposed to show synchronized play? > For a period of a couple of weeks, I also wired the Receivers as an attempt to > rule out the wireless network. This did not change anything. When setting that > up, I tried several things to disable wireless reception on the Receivers to > make sure that they were running over the cable. I couldn't figure out how, but > left the cables in (in both of them). I couldn't see anything about this in SC > and eventually concluded that they ignored the cables. And the cables didn't > improve on all the errors at all. You have to factory-reset the Receiver to change it from wireless to wired. Just plugging in a cable is not sufficient. > My personal theory is that the radio part of the Receivers is not as good as > the one in the Booms, and hence I have been thinking of trying two SB3s > instead, out of an assumption that SB3 share radio design with the Boom, just > as they share display - can you enlighten me here? The Receiver and Boom have the same wireless cards but the Boom does have an improved antenna configuration.
1: Is there anything more I can log/debug to clarify the problem? 2: Do you have any reaction/feedback on whether SB3's wireless capabilities are better than those of the Receivers? 3: Can you solve this problem for me with a software bugfix? Status at current: my two Booms still show no sign of problems at all! So a lot of music is being played these days :o)
ALan: I wonder if some judicious logging would be helpful here...
Shouldn't he run network test to see if it is a simple network transfer issue?
(In reply to comment #10) > Shouldn't he run network test to see if it is a simple network transfer issue? I have 2 Booms playing with no hiccups at all...
I'd still run network test against the units that fail.
I have tried running network tests, but I think it's hard to learn from. Running tests from the Controller, there is only very minor glitches @ 4000 kbps. All bars in the lower part are green. So I guess that doesn't help much. Are there other ways to test the network? When I look at the player status pages, the Receiver shows 68% signal quality, while a Boom placed just beside it shows 88%. It's 5 meters and line-of-sight. That is still bugs me. I think my next experiment will be to run two Booms wirelessly and one Receiver over cable. And then sync them all. Then add the second Receiver over cable.
Another network test that you could run would be to run ping from the server to each of the players.
Problem solved! What happened: I factory reset one of the Receivers in order to get it onto a wired connection in order to rule out (or in) the wireless circuit of the Receivers. On cable it was a 100% well behaved. For the first time ever I experienced flawless sync with my Receiver! After playing music a couple of days (and enjoying a lot of relief), I decided to try wireless again to see, if it was the factory reset that had helped. So now I factory reset both Receivers and connected them to wireless. Then I synced up all 4 devices (2 Duets + 2 Booms) in the same (big) room. Everything has now been playing without a single hiccup for 1½ weeks. I am now moving the Booms back at their previous places in other rooms. My own conclusions are, that some internal settings in the Receivers made their ability to sync flawed. These settings were not repaired with new releases of SqueezeCenter. Only a factory reset could clean this up. This is somehow related to my problems with my Boom's audio dying after trying to play net radio (as reported in bug 10651) - here it was the server's original ini file that caused the trouble. My first 14 months as a SqueezeBox owner has been very frustrating and now I sincerely hope that the trouble is over for good. Btw: if you decide to produce a Receiver Deluxe with Transporter DA converter and audio circuitry (but no XLR, just the same ports) - I will buy one right away. Thanks for now.
I would be very interested in hearing your feedback on my personal conclusions. I hope you are willing to share them. Best regards, Morten Schmidt
I don't know of any way that a factory reset could have somehow repaired wireless connectivity or otherwise the ability to sync.
Morten, what is the current status of this issue for you? Alan.
I am living happily with my setup. My wife is satisfied too :) Sound is good and sync is fine now. :o) I am thinking a lot about the operation of the setup - I miss some things, that I am not sure, I can get anywhere, like the concept of individual album/music collections like you would have in the physical world, where the kids would have their own CDs. I also need something more efficient for operating - I think the Controller is a bit tedious at times. For example: it sleeps to deeply when left outside it's cradle. I have also tested the 3 iPhone apps - they all have their good and bad sides. Thanks a lot for not forgetting my case. Have you any comments on my conclusions?
I am glad that things are working ok for you now. No, I do not have any other comment on your conclusions other than what I said in comment #17: I don't know of any way that a factory reset could have somehow repaired wireless connectivity or otherwise the ability to sync. I guess there could be something that I am overlooking. With the recently released 7.3.3 there have been some improvements to the way the Controller sleeps and wakes up. They may not cover all your issues but could well help.
(In reply to comment #20) > I am glad that things are working ok for you now. > > No, I do not have any other comment on your conclusions other than what I said > in comment #17: I don't know of any way that a factory reset could have somehow > repaired wireless connectivity or otherwise the ability to sync. I guess there > could be something that I am overlooking. > > With the recently released 7.3.3 there have been some improvements to the way > the Controller sleeps and wakes up. They may not cover all your issues but > could well help. Thanks for your reply, Alan, Regarding the effect of the factory reset: my theory is that the factory reset must somehow store some settings permanently in the Receivers. Some network timing stuff of some sort. The reset has definitely changed things "permanently", so something MUST have happened. I think that the best way to determine this is to review the code - which is beyond my own skill set, unfortunately. --- I am running SqueezeCenter 7.3.3.25698 and I will try to get it updated to the 7.3.3 release version soon - or maybe directly to 7.3.4 in the Windows Home Server flavor. --- Do you know if there is any plans for a "Album Collection" feature, and if so: can point me to page that discusses this? Best regards - and thanks - from Morten Schmidt