PDA

View Full Version : Delay between two synchronized SB's



soaringeagle
2008-11-20, 04:50
Hi,

I have a SB Boom and an SB Classic. Most of the time they stay in sync with one another and there is no noticeable delay between the two units.

However, occassionally for reasons that I'm still to work out, they get out of sync and a delay of 2 or so seconds is introduced. I have tried the following things,
- Stopping and starting a track
- Skipping tracks
- Unsyncing and Resyncing
- Stoppig and starting Squeeze Center.
- In and out of standby.

The only thing that I've found that reliably gets them back into sync is to disconnect the power and then to start them back up again.

As I'm new to SB's I don't know how they sync up. Would be great if someone could provide some insight into why the above things don't get it back into sync and cycling power is the only thing that seems to bring it back into life. Appeciate any hints as to what could be causing it, how to avoid it and how to snap it out of it in a more graceful way when they do get out of sync.

Thanks

Paul

oreillymj
2008-11-20, 05:18
Synching was greatly improved in 7.2.1, but is even better in 7.3. I've found it stays in synch perfectly when playing back local files stored on my server. I don't bother trying to synch internet streams as the web induced latency just makes it too hit & miss.

However, even in 7.2.1 the players should attempt to get back into synch.

If you look at the server settings page, you'll see some logging you can enable on various bits of the server including synch. Your server log will then be able to tell you what the players are up to.

But I think you should just hold out for 7.3 unless your prepared to try the beta. It's pretty stable at the moment as it's due for release sometime around early December.

http://downloads.slimdevices.com/nightly/SqueezeCenter_7.3_trunk_v2008-11-20/

andyg
2008-11-20, 05:50
All radio syncs fine in 7.3, what are you having problems with?

This page has some useful info: http://wiki.slimdevices.com/index.php/Synchronization

oreillymj
2008-11-20, 08:39
Andy,

I wasn't suggesting that internet radio in SC was flaky, rather that relying on Internet streams in general is a bit hit & miss depending on the broadcaster/ISP you're using.

As I said 7.3 for me is very solid.

soaringeagle
2008-11-21, 16:46
Guys. Thanks for the help.

I'm just trying to do a local sync using files served from SqueezeCenter. Enven though that is the main thing I'm trying to do, I've also had the problem with Internet Radio as well.

So, right now my system is having the issue. The delay is approx 3.2 seconds as you can see from the log,

-------------------------

8-11-22 10:35:24.3584] Slim::Player::Sync::checkSync (526) 00:04:20:1e:34:e3 checking buffer fullness: 4380 (threshold: 4096)
[08-11-22 10:35:24.3588] Slim::Player::Sync::checkSync (535) 00:04:20:1e:34:e3 is ready to sync
[08-11-22 10:35:24.3594] Slim::Player::Sync::checkSync (526) 00:04:20:12:74:6e checking buffer fullness: 0 (threshold: 4096)
[08-11-22 10:35:24.3599] Slim::Player::Sync::checkSync (526) 00:04:20:12:74:6e checking buffer fullness: 4380 (threshold: 4096)
[08-11-22 10:35:24.3602] Slim::Player::Sync::checkSync (535) 00:04:20:12:74:6e is ready to sync
[08-11-22 10:35:24.3608] Slim::Player::Sync::checkSync (526) 00:04:20:12:73:d6 checking buffer fullness: 0 (threshold: 4096)
[08-11-22 10:35:24.3831] Slim::Player::Sync::checkSync (526) 00:04:20:12:73:d6 checking buffer fullness: 4380 (threshold: 4096)
[08-11-22 10:35:24.3834] Slim::Player::Sync::checkSync (535) 00:04:20:12:73:d6 is ready to sync
[08-11-22 10:35:24.3836] Slim::Player::Sync::checkSync (561) all clients ready to sync now. unpausing them.
[08-11-22 10:35:24.3839] Slim::Player::Squeezebox2::startAt (905) 00:04:20:12:73:d6 startAt: 60456655
[08-11-22 10:35:24.3846] Slim::Player::Squeezebox2::startAt (905) 00:04:20:1e:34:e3 startAt: 233429857
[08-11-22 10:35:24.3852] Slim::Player::Squeezebox2::startAt (905) 00:04:20:12:74:6e startAt: 233445274
[08-11-22 10:35:26.0681] Slim::Player::Player::trackJiffiesEpoch (916) 00:04:20:12:73:d6 adjust jiffies epoch +0.005s
[08-11-22 10:35:27.0121] Slim::Player::Sync::checkSync (641) 00:04:20:1e:34:e3 bailing as no playPoint
[08-11-22 10:35:27.0333] Slim::Player::Player::trackJiffiesEpoch (916) 00:04:20:12:74:6e adjust jiffies epoch +0.005s
[08-11-22 10:35:28.9505] Slim::Player::Player::trackJiffiesEpoch (916) 00:04:20:1e:34:e3 adjust jiffies epoch +0.005s
[08-11-22 10:35:28.9510] Slim::Player::Sync::checkSync (652) 00:04:20:12:74:6e bailing as playPoint too old: 3.22789931297302s
[08-11-22 10:35:29.9489] Slim::Player::Sync::checkSync (652)
------------------------------------------

Each time that I skip a track, it is starting from the same offset e.g. if it ended up at 3.1 seconds after the end of the track, it starts at this offset for the next track. Right now it is only the one device that is out of sync, the other two are working fine.

File type that I'm using right now is WMA.

As I mentioned in my original post, the only sure way I've find right now to get rid of this offset is to disconnect the power of the offending unit and power it up again. On a reboot it seems to do something different then happens on a track skip.

Can either of you provide an insight as to how this offset gets introduced originally? Do the devices try and do a clock sync and for some reason one device on my network is getting a different time?

soaringeagle
2008-11-21, 16:46
Using 7.2.1 by the way.

Just cycled power on all the units and they are now in sync again.

--------
[08-11-22 10:55:28.1986] Slim::Player::Sync::checkSync (669) playPoints: 00:04:20:12:73:d6: 1227311689.185, 00:04:20:12:74:6e: -1, 00:04:20:1e:34:e3: +0
[08-11-22 10:55:29.1984] Slim::Player::Sync::checkSync (669) playPoints: 00:04:20:12:73:d6: 1227311689.184, 00:04:20:12:74:6e: +0, 00:04:20:1e:34:e3: +0
[08-11-22 10:55:30.1990] Slim::Player::Sync::checkSync (669) playPoints: 00:04:20:12:73:d6: 1227311689.185, 00:04:20:12:74:6e: -1, 00:04:20:1e:34:e3: -1
[08-11-22 10:55:31.1984] Slim::Player::Sync::checkSync (669) playPoints: 00:04:20:12:73:d6: 1227311689.184, 00:04:20:12:74:6e: +0, 00:04:20:1e:34:e3: +0
[08-11-22 10:55:32.1982] Slim::Player::Sync::checkSync (669) playPoints: 00:04:20:12:73:d6: 1227311689.184, 00:04:20:12:74:6e: +0, 00:04:20:1e:34:e3: -1
----------

soaringeagle
2008-11-23, 14:05
Some more information,

- Restarting SqueezeCenter also seems to bring all devices back into sync again (in addition to cycling the units). When I previously said that this didn't help, I wasn't shutting down SqueezeCenter properly.
- I am running SqueezeCenter inside of a virtual machine. So, I suspect it has something to do with time drift of that virtual machine.
- Think that it is only getting out of sync if I have not used my computer for a while. BTW, virtual machine is always on and running at the highest priority i.e. it has not gone into standby.
- Offset seems to be pretty consistent at around 3.4 seconds and seems to be impacting one box more than others e.g. this morning when I woke up, two units were in sync and another was running ahead of those two units. So, they're not all out of sync.

Understand that this setup is probably non compliant. Therefore, if someone has a summary of how synchronization works, I should be able to narrow down the problem.

Thanks

nwplace
2008-11-24, 12:56
[QUOTE=soaringeagle;362888]Some more information,

- Restarting SqueezeCenter also seems to bring all devices back into sync again (in addition to cycling the units). When I previously said that this didn't help, I wasn't shutting down SqueezeCenter properly.

/QUOTE]


I had similar sync problems and restarting SqueezeCenter or rebooting the server would only resolve it for a several hours after the restart/reboot and the boxes would again start to play out of sync. The problem turned out to be due to clock drift on the pc running SqueezeCenter.

Links to my original post and the bug that I filed:

http://forums.slimdevices.com/showthread.php?t=45610

http://bugs.slimdevices.com/show_bug.cgi?id=8018
Edit/Delete Message

soaringeagle
2008-11-29, 06:31
Thanks nwplace. Valuable information.

Your logs are close to what I was seeing. Because I'm running Squeeze Center inside of a virtual machine, I'm susceptible to clock drift. The clock of my virtual machine is locked to my physical machine, however depending on the what is happening inside of the virtual machine, it may fall behind on clock ticks only to catch up later.

I've found that when the virus scanner runs (which is a period of high load on the virtual machine) that is when they get out of sync the most.

Can anyone tell me,
1) Why when the load disappears on Squeeze Center and time gets back into lock step again, do the Squeezeboxes not get back into sync again? It seems that after this load, they will remain out of sync until Squeeze Center has been restarted.
2) What is Squeeze Center doing on the restart that resyncs the units again? Is there a way to make this happen periodically?

I know that this is a not a normal setup and that if I installed Squeeze Center on a physical box, then this problem would happen. However, I'm trying to see how good I can make things work in a virtual environment before resorting to that as I run everything virtual.

If there is anymore work done on syncing in the future, it would be nice to have syncing be independent of what is going on in the squeeze center box.

Thanks

Paul