Bugzilla – Bug 10320
Time command should remain paused if paused
Last modified: 2009-10-05 14:33:04 UTC
If play is paused, the time command changes the play time and resumes play at the new time. It should simply change the play time. A subsequent play command would be required to resume play. I'm pretty sure that this behavior is new in 7.3.
Why would you want to jump without playing? I think this is by design.
1. If this behavior is intentional, it ought to be described in the documentation. 2. We could probably debate the correctness of combining play with the time command and never agree. What should happen when playback is paused and the user jumps the time? You say that the play time should change and play should resume. I say that the play time should change and play should *not* resume until the user clicks the play button. To me it seems like a surprising side effect that play would resume without clicking the play button. If the user intentionally paused playback, he clearly does not want the unit to be playing. If he then jumps the time, he still has not countermanded his desire for playback to be paused. If he wanted the unit to be playing after changing the play time, he would not have paused first. He would simply have changed the play time while the unit was playing. 3. You might argue that if I really want playback to remain paused, I could detect the paused state before issuing the time command and then issue a pause command if playback was previously paused to restore the paused state. This sequence does not work when I issue the command programmatically. After issuing the time command, I detect is_paused False (using the mode command). I issue the pause command. is_paused is still False. When I issue the same commands manually, they work. I have not been able to resolve the discrepancy. However, it seems as if there is another bug preventing me from implementing a workaround.
Alan: Your comments on this one one?
This was a sort-of deliberate change in 7.3 and reverses the decision in the resolution for bug 7497. I'm not sure how easy this would be to change back with new-streaming. I'll consider it for 8.0.
In the meantime, can you suggest a workaround? This change in 7.3 has broken my program, so I can't wait for 8.0.
I'm sorry, but I cannot think of an easy workaround. I'll let you know if I come up with one. So you have your own control app of some kind?
Yes. Is there a way to get back to version 7.2? Although 7.3 fixes several bugs that I reported, I know how to work around them, whereas I do not know how to work around the new bug in 7.3.
Change 27387.
This bug has been marked as fixed in the 7.4.0 release version of SqueezeBox Server! * SqueezeCenter: 28672 * Squeezebox 2 and 3: 130 * Transporter: 80 * Receiver: 65 * Boom: 50 * Controller: 7790 * Radio: 7790 Please see the Release Notes for all the details: http://wiki.slimdevices.com/index.php/Release_Notes If you haven't already, please download and install the new version from http://www.logitechsqueezebox.com/support/download-squeezebox-server.html If you are still experiencing this problem, feel free to reopen the bug with your new comments and we'll have another look.