Bugzilla – Bug 9219
Using the time command to jump relative does not work
Last modified: 2009-07-31 10:27:40 UTC
Consider this dialog with SqueezeCenter using the CLI: 00%3A04%3A20%3A16%3A42%3Af7 play 00%3A04%3A20%3A16%3A42%3Af7 play 00%3A04%3A20%3A16%3A42%3Af7 time ? 00%3A04%3A20%3A16%3A42%3Af7 time 5 00%3A04%3A20%3A16%3A42%3Af7 time ? 00%3A04%3A20%3A16%3A42%3Af7 time 10 00%3A04%3A20%3A16%3A42%3Af7 time +60 00%3A04%3A20%3A16%3A42%3Af7 time %2B60 00%3A04%3A20%3A16%3A42%3Af7 time ? 00%3A04%3A20%3A16%3A42%3Af7 time 85 00%3A04%3A20%3A16%3A42%3Af7 time -60 00%3A04%3A20%3A16%3A42%3Af7 time -60 00%3A04%3A20%3A16%3A42%3Af7 time ? 00%3A04%3A20%3A16%3A42%3Af7 time 132.004451113621 00%3A04%3A20%3A16%3A42%3Af7 time ? 00%3A04%3A20%3A16%3A42%3Af7 time 132.004451113621 00%3A04%3A20%3A16%3A42%3Af7 mode ? 00%3A04%3A20%3A16%3A42%3Af7 mode play 00%3A04%3A20%3A16%3A42%3Af7 time ? 00%3A04%3A20%3A16%3A42%3Af7 time 132.004451113621 I start play. You can see time advancing. I jump ahead 60 seconds. The time advances, though probably by more than 60 seconds (it takes a few seconds to enter the command each time). What is clearly wrong is what happens when I jump back 60 seconds. The time advances by about 70 seconds and the sound output stops. The time does not change anymore even though SqueezeCenter is still reporting that we are in play mode. Also note that I suddenly start getting time reported in floats. It is possible to restore sound output by stopping and starting again. Setting time to a negative relative jump does sometimes actually jump time backwards, but always the amount seems random. In fact, the amount of relative jump in either direction is unpredictable.
One other small point: The documentation should explain what happens when a relative jump command exceeds the bounds of the track. I believe that a jump to a time prior to the start of the track should be truncated to the start of the track and then proceed normally. A jump to a time beyond the end of the track should be truncated to the end of the track and the state machine should advance as it would have had the end of the track been reached normally. I have designed around this bug using absolute jump. With an absolute jump, I can limit the jump time to times that are actually in the track (but note bug 9220).
Alan: This yours?
Yes. The old behaviour was in fact for relative jumps outside the bounds of the current track to jump to somewhere within the adjacent track. With s 7.3 out-of-track jumps are not allowed. But in any case, there is no core SC code that makes use of relative jumps, at least not that I am aware of. I note that the NS code does not enforce the boundaries properly.
Fixed in 7.3 (after correcting a silly typo): change 22959
This bug has been fixed in the 7.3.0 release version of SqueezeCenter! Please download the new version from http://www.slimdevices.com/su_downloads.html if you haven't already. If you are still experiencing this problem, feel free to reopen the bug with your new comments and we'll have another look.
Reduce number of active targets for SC