Bug 7068 - Fast-forward/rewind is broken on controller
: Fast-forward/rewind is broken on controller
Status: CLOSED FIXED
Product: SB Controller
Classification: Unclassified
Component: UI
: unspecified
: All All
: -- major (vote)
: 7.1
Assigned To: Alan Young
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2008-02-10 08:53 UTC by Max Spicer
Modified: 2009-09-08 09:19 UTC (History)
2 users (show)

See Also:
Category: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Max Spicer 2008-02-10 08:53:35 UTC
The fast-forward/rewind behaviour is currently broken on the controller.  It should either be fixed before 7.0 is released or should simply be removed.  Removing it would be an improvement on leaving it as it is now!

Problems:

- There's no feedback on the controller to tell you that you have activated fast-forward or rewind (unless you notice the progress moving quicker).
- Once you've activated it, the only way to cancel it is to press pause *several* times.  The first press of pause during ffwd/rewind mutes the sound but leaves the player playing (the visualisers continue and progress moves on).  The second pause pauses, the third pause starts it again.  Worse still, the first press of pause triggers a Now Playing notification.

Play should cancel ffwd/rewind, as should pause but without the odd behaviour.

The above-described pause behaviour is easily reproducible but does not occur absolutely every time.  Similar behaviour occurs when I use the ir-remote to pause a player whilst it's scanning, however I haven't yet managed to get it to do the muted playback behaviour.  All tests have been done against my transporter.
Comment 1 Max Spicer 2008-02-10 08:59:10 UTC
Forgot to give versions - SqueezeCenter 7 branch R17379, Jive 7.0 r1879
Comment 2 KDF 2008-02-10 09:08:50 UTC
severity abuse. While this could be considered a pet peeve issue, fwd/scan is not a critical functional feature.  There is no data loss and SC isn't crashing or failing to run.  Lets keep the blockers for real blockers please.  If severities are abused, they begin to become meaningless.

if something is critical for 7.0, I suggest we revert and reopen bug 5333.
Comment 3 Max Spicer 2008-02-10 09:23:11 UTC
Apologies - was getting confused with the request blocking feature on Mozilla's bugzilla.

I would agree that the solution for 5333 should be reverted.  By the looks of things, that bug was closed way too early!
Comment 4 Blackketter Dean 2008-02-10 21:19:56 UTC
Alan's thinking hard about the scanning UI.  Will look at this for 7.0.1.
Comment 5 Alan Young 2008-02-27 09:51:18 UTC
*** Bug 7341 has been marked as a duplicate of this bug. ***
Comment 6 Richard Titmuss 2008-03-11 14:10:28 UTC
This is now a 7.1 fix.
Comment 7 Alan Young 2008-04-16 09:58:48 UTC
*** Bug 7820 has been marked as a duplicate of this bug. ***
Comment 8 Alan Young 2008-04-21 23:26:19 UTC
The latest build includes a new scanner function, similar to that with the new Scanner plugin for the player-UI. It does not include accelerated-audio support at present and I do not currently plan to add it. Note that this is on the 7.1 trunk.
Comment 9 Max Spicer 2008-04-22 01:35:58 UTC
What are the thoughts on accelerated audio playback in general?  If it stays in the squeezebox ui, it could be confusing to omit it from the controller and people will ask for it.
Comment 10 Alan Young 2008-04-22 01:56:24 UTC
Max, You have seen the threads in the forums. The thoughts are various and strongly felt. Virtually all those who have bothered to express an opinion have said that they do not need accelerated audio. There are one or two vociferous objections. Alan.
Comment 11 Marc Auslander 2008-04-22 17:59:46 UTC
IMHO, the best searching interface is the one in WinAmp using the left/right cursor keys.  The idea is that you can skip forward or back very quickly, and everytime you stop the audio starts playing (almost) immediately at the current point.  Speed comes by having a very responsive interface so repeated clicks work as fast as your finger can press, moving about 5 seconds/click, and much higher speed, sort of 1 minute steps, when you hold the key.  Overshoot doesn't matter cause going back is so easy.

The scanner mechanism is very close to this - except the delay to start playing is too long.

Scanner now works both in SB3 using up/down and controller using the knob.

I personally can't imagine using the old fast forward stuff in preference to this.  In fact, long ago I started using the scanner plug in and never used fast forward again.
Comment 12 Alan Young 2008-04-23 23:54:59 UTC
With the controller it is 1.3s delay. It could probably be shorter for local tracks and probably should be a little longer for remote tracks.
Comment 13 Alan Young 2008-05-07 05:19:01 UTC
Now you get 400ms for local streams and 2s for remote ones.
Comment 14 Alan Young 2008-06-04 07:26:58 UTC
Marking fixed.
Comment 15 Chris Owens 2008-07-30 15:28:16 UTC
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.
Comment 16 James Richardson 2008-12-15 12:38:09 UTC
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.