Bugzilla – Bug 1592
Fast forward / rewind rework
Last modified: 2011-03-16 04:39:18 UTC
Fast forward and rewind modes remain active even after changing tracks or completely powering off the player. The mode should be reset to "Play" if the user manually changes the track or powers off.
Andy: can you give some exact steps to reproduce this problem? I don't see it here.
according to the code, it is by design that a jump fwd or jump rev (fwd.single and rew.single) will have no effect if the player is already scanning in that direction. Only play, pause or stop has any effect. Pressing in the opposite direction will do what the usual function does. power appears to have no effect intended.
using softsqueeze to test: FFWD into 2X mode power off power on now playing - shows as paused press pause goes into 2x mode. FWD while in FFWD has no effect (just as the comments in code suggest) REW while in REW2X has no effect either. adding $client->execute(["stop"]); as part of the 'power' button code in Common.pm has the effect ot placing the player in stop mode when power button is pressed, and resets scanning to normal. Pressing pause or play when powering on thus starts playback at normal speed, from the beginning of the track.
seems very reasonable.
then teh remaining question is whether the FWD and REW functions stay as designed, or do they reelly make more sense returning to rate=1?
The idea is that you press and hold the FWD and REW buttons to go into the scan mode, and press the other direction to stop them and continue. I'd like (post 6.1) to see if we can get it to work so that the scan only stays on while holding (it's a bit of a trick given the unreliability of IR), but it would improve usability substantially. Scan speeds should be reset when powered off (and a stop seems like a reasonable way to do that).
ok, I'll merge in the stop for tonight and remark this as 'future' when that's been done.
committed power off fix at change 3705. marking remainder for future review.
retitling to the specific task, as an enhancement
*** Bug 2284 has been marked as a duplicate of this bug. ***
Is this still an issue in 6.5?
yes. the original request is for FWD and REW scanning while holding the button only. the current function is that holding the button starts scanning 2X, then hold again scans at 4X. there is another request for the function to increase scanning without hold. Both the current function, and this reqest are existing methods in other consumer equipment. Requires a final ruling on how it should be implemented. Of course, it should then be hardened to function very well under that design.
Compare to other bugs about ff rev behavior, and consider whole interface.
*** Bug 1911 has been marked as a duplicate of this bug. ***
*** Bug 2098 has been marked as a duplicate of this bug. ***
Sorry for the confusion. We're going to fix this ui problem by making press and hold start fast forwarding and releasing the button ending the fast-forward. We'll also have the fast-forwarding ramp up over time.
Is that a good idea? I think I would actually prefer the way it currently works, rather than having to keep FFWD/REW held down and the remote pointed at the squeezebox. I feel the current method has more benefits, as I am more in control. Could you at least consider a preference setting to select the desired ffwd method?
(In reply to comment #17) > Sorry for the confusion. We're going to fix this ui problem by making press and > hold start fast forwarding and releasing the button ending the fast-forward. > We'll also have the fast-forwarding ramp up over time. > Yes! I'm so happy to hear this! But I agree with Phillip that this should be an option available in Preferences for those who prefer the old method of scanning.
(In reply to comment #17) > Sorry for the confusion. We're going to fix this ui problem by making press and > hold start fast forwarding and releasing the button ending the fast-forward. > We'll also have the fast-forwarding ramp up over time. Actually, I'd like to have a constant speed FF/RW when holding down a button to seek. Acceleration could make it very hard to stop at a desired point, unless it only kicks in very slowly. Perhaps that could be an option too: acceleration on/off. Also, the current seeking implementation doesn't work very well when seeking backwards. When you hit the beginning of the current playing file, a rebuffering time-out happens. I haven't had this problem when seeking forward through files. I presume this is because the buffer only reads ahead of the current play position and empties a song from the buffer as soon as it is finished playing. Furthermore, I'm guessing that the buffer does not start buffering backwards if the user starts seeking backwards; it just scans backwards through the current track in the buffer. But, I've not looked at the code so this is all a guess in the dark of what's really going on in the code. At any rate, I'd like to seeking to be seamless in either direction. Maybe this should be a new bug or is it the same as: https://bugs-archive.lyrion.org/show_bug.cgi?id=2942
Alan: Is this bug something you think you could tackle in the 7.0 timeframe?
The planned changes for this are a little too widespread to fit in in time for 7.0 so pushing this out to 7.1.
*** Bug 108 has been marked as a duplicate of this bug. ***
Changed summary to cover wider goal. See also http://forums.slimdevices.com/showthread.php?t=41132
*** Bug 1649 has been marked as a duplicate of this bug. ***
New scanner committed with change 18128.
This bug has now been fixed in the 7.1 release version of SqueezeCenter! Please download the new version from http://www.slimdevices.com 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