Bugzilla – Bug 11101
SqueezeNetwork data center sync / acquisition issues
Last modified: 2009-09-08 09:16:23 UTC
See my posts at http://forums.slimdevices.com/showthread.php?t=58263. (Significant note: I do not use SC except for debugging purposes -- I'm 100% SN.) This morning my SBR was playing internet radio, my Boom was playing Slacker, and I turned on my SBC. It couldn't see any players. After 'factory resetting' it and hard-rebooting the SBR, the controller was able to see it and normal behavior resumed. Except that the SBC still can't see the Boom, which is happily playing Slacker stuff. SBR and Boom are on SN, playing music, but only one is seen by the SBC. What's up? The Boom's connected to Sunnyvale and the SBR is connected to Ashburn, that's what. nat.dc.squeezenetwork.com shows the SBC and SBR as being connected and Boom as unconnected. nat.sv.squeezenetwork.com shows all three devices as being connected. Currently, www.squeezenetwork.com resolves to nat.dc.squeezenetwork.com's IP in DNS. I'm in Petaluma, CA. Whether SN's servers are three load balancers to centralized/replicated databases or "local" servers in the sense that geographic location X always connects to the server closest to X, something's not working right. Either mirrored data isn't being mirrored, or location X is connecting to server Y when it's not supposed to. Or am I missing something? How do I get the SBC to see both players, and how do I get www.squeezenetwork.com to see both players?
Not really a bug, just a side effect of getting on multiple datacenters.
This is a bad user experience, shouldn't all players be seen on all data centers?
If player functionality is unavailable to either SN's web UI or the SBC (or both), is this not a bug? Please advise.
You ran into an unfortunate situation where you were using multiple datacenters and there was replication lag for the database. This is an operational issue, not a bug. We're doing a big release tonight that includes a lot of database fixes, and may help with this.
..."unfortunate situation where you were using multiple datacenters and there was replication lag for the database" Is it possible that this is the cause of my alarm failure this morning? Last night I checked my alarms -- my 6:01 alarm was off, so I turned it on. I then checked SN settings (connected to Sunnyvale), set the Boom for an hour of sleep, and double-checked that the next alarm was set for 0601. So far so good. This morning I was awake and watching the Boom as it changed to 0601 and nothing happened. I waited until 0602 and then checked alarm status -- my 0601 alarm was off! And I was connected to Ashburn. In every instance where I have noticed SN discrepancy issues, Sunnyvale knows everything that's going on, but Ashburn doesn't. e.g., nat.sv.squeezenetwork.com knows that my devices are connected even if one or both of them are connected to Ashburn, but nat.dc.squeezenetwork.com doesn't see anything connected to Sunnyvale. As I was connected to Sunnyvale last night when I made an alarm change, and connected to Ashburn this morning after the alarm failure, it seems to me that a data replication bug definitely exists. If this is truly an operational issue, please tell me how to operate my Squeezebox devices in order to avoid the problems. Thank you.
Yes, but the lag issue is resolved as of this morning.