My guess is the problem is the SB1s. In terms of maintaining synchronization, this is the hardest case - SliMP3s are actually better. And I must admit that I have done less testing with SB1s that with other player types. I would certainly not rule out a logic bug in this case.
Do you always have both SB1s in the sync-group when the problems arise? Basically, sync works best with SB2-and-above player types - these have specific protocol support for sync management. If you add just one SliMP3 or SB1 to the mix, then the algorithms will always use the more-capable adjustment mechanisms of the newer players. But once you have two or more of either SliMP3 or SB1s, then more-primitive adjustment mechanisms sometimes have to be used, and these are particularly hit-and-miss with SB1s. I have not done any testing with two SB1s in the mix. When you play local FLAC files, these will have to be transcoded to a common format supported by both SB1s and SB3s (assuming that you have both in the sync-group). Do you know if your configuration is using WAV or MP3 in this case? I admit that I have done no testing of sync when WAV is being streamed. But, in any case, I presume that for Internet radio streams, these are in MP3 and so will not be locally transcoded. The fact that the problem persists with local tracks after first loosing sync on a radio stream is particularly interesting. If you were able to reproduce this with logging set to player.sync=debug and then open a bug (bugs.slimdevices.com) for this, attaching the log along with a commentary of what happened when, this would be useful. Alan. -- awy ------------------------------------------------------------------------ awy's Profile: http://forums.slimdevices.com/member.php?userid=7480 View this thread: http://forums.slimdevices.com/showthread.php?t=38054 _______________________________________________ beta mailing list [email protected] http://lists.slimdevices.com/lists/listinfo/beta
