Bugzilla – Bug 14570
Apple Dual-Band Airport seemingly incompatible with SqueezePlay-based Squeezeboxes
Last modified: 2011-11-06 23:23:46 UTC
In the saga of ongoing sync issues, heres a log file from syncing that is failing miserably this morning. I have two players, both are on separate Airport Extreme's (graph attached), each running on 2.4GHz. Both players Synced playing Pandora worked great for ~4 hours. I started playing FLAC albums... everything seemed OK. At one point I had to reboot an airport for a configuration change. When it came back up, nothing worked after that. The songs keep restarting at the beginning, and the Boom is playing the audio but the baby just keeps 're-buffering'. Playback never really starts up. Skipping the song did not solve the issue either. In order to solve the issue I had to physically reboot the Baby. When it came back up, playback started working again.
Created attachment 6009 [details] server.log of the failing sync
Created attachment 6010 [details] Bandwidth graph from Airports You can see here that at around 12:05 or 12:10 I started the playback. The playback was fine for about 10 minutes before the playback problems began and the bandwidth drops to near zero. I rebooted the Baby somewhere around 12:25-12:30 and then playback begins to work again. These are the only two devices (other than two jives) on the 2.4GHz spectrum in my house...
The rebuffering problem just started again. There were no wifi interruptions this time, it just happened on its own and will not resolve itself. (other than perhaps rebooting the baby). Looking at the Baby itself you can see its CPU is maxed out. I can barely type on it via remote SSH. Mem: 52952K used, 9136K free, 0K shrd, 7312K buff, 16624K cached CPU: 72% usr 27% sys 0% nic 0% idle 0% io 0% irq 0% sirq Load average: 1.86 1.99 1.66 3/65 1188 PID PPID USER STAT VSZ %MEM %CPU COMMAND 740 1 root R 30036 48% 57% /usr/bin/jive 1187 1184 root R 2692 4% 19% top 783 740 root S 7108 11% 10% jive_alsa -d default -c dac -b 20000 -p 2 -s 16 -f 3 731 1 root S 1892 3% 5% /usr/sbin/wpa_supplicant -B -Dwext -ieth1 -c/etc/wpa_supplicant.conf I've attached the messages file with the last 1000 lines in it or so. It's clearly having some kind of playback issue that I think is causing the sync issue actually.
Created attachment 6011 [details] Last 1000 lines of messages file from misbehaving baby
After that 1000 line log I postd above, Baby rebooted on its own. Its come back up and is continuing to have audio underrun errors.
Ok... more info. I switched from FLAC to Pandora. The players are currently playing, but I am still seeing audio underrun errors. The sync is off by a good 2-3 seconds and staying that way right now.
*** Bug 14567 has been marked as a duplicate of this bug. ***
*** Bug 14626 has been marked as a duplicate of this bug. ***
Is this a dupe or related to bug 13092?
Alan is pretty darn sure that the other bug is a network issue. I can easily pass the 5000KBPs stream test in my house with multiple players at the same time -- so its not a bandwidth issue.
Created attachment 6050 [details] 7.4 official Server.log FLAC and Rhapsody sync errors My original bug got closed as a dupe, but it's not entirely the same as this bug, but anyway. Running 7.4 official receiver is 4-5 seconds ahead of boom when syncing FLAC or Rhapsody. Attaching server.log with player.info and player.sync debug info. Please let me know if you need anything else thanks.
Created attachment 6051 [details] 7.4.1-28791 still Rhapsody and FLAC sync errors I upgraded to SqueezeboxServer-7.4.1-28791. Now it seems one receiver and one boom syncs ok with FLAC but still no Rhapsody sync. Adding another boom to the sync group breaks sync for both FLAC and Rhapsody.
Created attachment 6069 [details] SqueezeboxServer-7.4.1-28791. MP3 sync not tight Here is another server.log. This time it's an mp3 playing. Sync was kinda of there, but seemed somewhat off still. Less than 0.3 seconds though. Does this log show any sync errors?
Nikolaj, It looks like something is messing with your server clock. What do you use to set the time on your server?
Matt, some definite weird stuff in your log. What are all the Slim::Player::SqueezePlay::updateCapabilities (128) unknown capability: ---=1, ignored lines about? Can you capture a connect with network.protocol.slimproto=info enabled so we can see the capabilities being passed please?
(In reply to comment #14) > Nikolaj, It looks like something is messing with your server clock. What do you > use to set the time on your server? It's a windows 7 ultimate server that currently uses "Internet time" synchronization.
- I did a resynchronize time which set the server back 1-2 minutes and restarted the server. Now Rhapsody, mp3, flac and internet radio seems to sync well between the two booms. Anything I should do to avoid the server time causing problems? Using a fixed clock?
Alan, Andy says that error is normal -- it has to do with a line being commented out of the transcoder config file. I'll get a capture next time I can reproduce this with the logging you requested though. For what its worth, I think that some of this might be solved with with the now playing screen memory leak bug... I was having serious playback issues this morning and it turned out I was out of memory.
...not my bug to own
The --- is the disabled ALAC codec.
Well I'll be damned... on a whim I decided to turn Wireless off on my (farther away) "server room" Airport (Gig-E, Single Band, N). When I did that, I actually nearly lost the entire ability to stream FLAC at all! I had a Boom (wireless, 20ft from dual-band airport, line of sight), a Baby (wireless, 20 ft from airport, one wall in the way), and a Touch (wired ethernet) synced... I couldn't get ANY music to play. Rebuffering all over the place, Boom even had such a hard time with the wireless that it crashed and rebooted! I switched things around... disabled WiFi on my Dual-Band GigE airport completely and turned WiFi back on the server room airport (which is farther away, through multiple walls)... almost instantly music started playing out of all 3 players! SYNCED! I think I might be crazy... but we'll see how it plays tonight. I suspect that there is something wrong either with my dual band airport, or the interaction between this airport and our products... the syncing is now damn near perfect, and all the players are very responsive! If this continues to work all weekend, I'll bring the airport into the office on Monday for further examination.
Nikolaj, I'm not sure what to suggest as I'm not sure what options are available under Windows. Ideal would be an NTP client running continuously. The sync code does not really like small jumps backwards in server time (where 30ms < small < 50s). The fix proposed in bug 14352 may be of help, but this is not yet committed for release. Otherwise, restarting SC after the time adjustment would be one option, or running the time adjustment sufficiently often that all the adjustments are small.
- Thanks for the response Alan. I'll see what I can find regarding timesync. I do think that many users will have similar windows setups, so it would be great if the code could handle these time updates transparently.
- I have used this tutorial: http://www.cumps.be/howto-set-up-ntp-on-windows-vista/ To set ntp updates to every 12 hours. Was set to every 7 days as default. Let's see if that helps.
Just another comment from the forums that echoes the issues I have had: http://forums.slimdevices.com/showpost.php?p=471116&postcount=7 "I had one and had problems with SBs, so I sent it back."
*** Bug 14368 has been marked as a duplicate of this bug. ***
- this morning players were out of sync again. Skimming the logs it shows that the ntp updated _after_ squeezebox server started after my daily scheduled reboot. Gonna try and schedule a manual ntp update before the reboot and disable automatic ntp updates.
Nikolaj, If you continue to have issues related to the NTP problem, could you please open a separate bug. It seems that this bug really has been broken down into an incompatibility with Apple Dual Band Airports. Felix, It seems that there are multiple reports of problems with the Dual Band airport. Do you expect this to be an issue you can solve remotely, or should we just send you the airport ASAP so that we can get a fix in for 7.4.x+? This is the only Airport Extreme that Apple ships now, so its likely to become a worse and worse issue as time goes on.
FWIW, my dual-band AE has been working great.
Matt: I talked to Richard about this and we both think it has something to do with having two APs running than one being dual band. For now he suggests the following: - Turn off all your players (i.e. take them off the wireless network) - Only configure _one_ access point - Turn on your players again (i.e. reconnect them to your network) - Test if you still see the issue - Repeat above with your other access point Thanks Felix
Moving these bugs to P4 to make room for moving P1.5 bugs to P2
Administrative move of 7.5 bugs. All P2, P3, P4 being downgraded one level. Will then split P1s.
Matt, why is this bug assigned to you again?
This can't be a deal breaker.
Hah, i have no idea why this is assigned to me. That seems like a mistake.
Moving P3 and lower bugs to next release target
Unassigned bugs cannot have a priority.