It certainly seems plausible. I'm not sure why that'd happen -- SyncOptions only alters the playlist (restoring a saved playlist, which could be empty) when a client 1) unsyncs from a group OR 2) powers *off* with SyncOptions set to unsync at power off Neither condition seems to hold here.
I could imagine a problem if - player 69 is playing - player F3 is quiet and has no playlist - someone asks player F3 to sync to player 69 and - SyncOptions was configured to wait until the next song - player F3 turns off before 69 hit a new song - ...time elapses... - player F3 wakes up to play an alarm - player 69 *stops* playing its song - SyncOptions notices the song on 69 has stopped (sees new song NONE), and syncs F3 to 69 That would explain both being quiet. Might something like that have happened? At that point, there should be a saved playlist for F3, but I can't immediately see another explanation for SyncOptions sabotaging F3's alarm. SyncOptions should probably give up on syncing F3 to 69 when F3 powers off, and when an alarm starts on F3. Similarly, if SyncOptions notices that a would-be-master stops playing music, it should probably forget about all the would-be-joiners, though that could get tricky for would-be-joiners still displaying "waiting for next track" screens. Alternately, SyncOptions could wait until the would-be-master started playing an actual track to join others waiting on it. -- peterw http://www.tux.org/~peterw/ free plugins: http://www.tux.org/~peterw/#slim AllQuiet BlankSaver ContextMenu FuzzyTime KitchenTimer PlayLog PowerCenter/BottleRocket SaverSwitcher SettingsManager SleepFade StatusFirst SyncOptions VolumeLock ------------------------------------------------------------------------ peterw's Profile: http://forums.slimdevices.com/member.php?userid=2107 View this thread: http://forums.slimdevices.com/showthread.php?t=53978 _______________________________________________ plugins mailing list [email protected] http://lists.slimdevices.com/lists/listinfo/plugins
