>There is considerable dissatisfaction with the current implementation, >although I suspect that it probably >meets the needs of some people just fine. > Can you recap what features of the current functionality users are dissatisfied with? Maybe there's just a lack of information on how it works and people need some extra words in the documentation.
Are users actually saying that they don't like the sound made when fast-forwarding, or is that just an internal thing because Logitech want to make the software easier to understand? Do users understand that they have to hold the FF button down? Do users understand that they can release and hold again to go faster? Do users understand that they have to press play to resume normal playback? I'm trying to understand where the dissatisfaction is. >Let me start by recapping on the current functionality, as I understand >it. >From this statement it does sound like there's no written documentation. I >can't find my original user manual. I've looked in the Help->Remote Control >Reference, and all it says is "Press and hold FWD to scan forward through the >current song." Whilst that statement is not untrue, it doesn't really detail the whole functionality. Your recap of the functionality was really good - and at least one user replying to this thread now undertands how it is meant to work. I suggest that as part of the rework (if anything has to be done), you also consider writing some details into the help reference, and eventually it would be good if Logitech release a better user manual for new products. >There is considerable doubt about whether being able to hear the 1s >chunks of audio in these modes is actually of any use. > Really? Where does the doubt come from? I find it very useful, and I would find it useless without. Most other playback devices have audio feedback - CD players and mp3 players. Take for example the industry standard for mp3 playback devices - the iPod. If you press and hold the >> button on an iPod, it will fast forward, playing chuncks of audio in exactly the same way as the SqueezeBox fast-forward implementation. Comparing to VCR/DVD/PVR devices, they all show a visual feedback when fast forwarding through video. Video players often had two mechanisms too. Fast-forward when playing will give a visual feedback, so you know when to stop fast-forwarding through adverts, for example. When stopped, fast-forward would go faster, showing a time position, so you can set playback at a particular point in time. The iPod also has two mechanisms for seeking through a song. 1. Press and hold >> to fast-forward with audio feedback. 2. Press the middle circular button to go to a song progress bar. The wheel is then used to set a specific position within the song. The music plays at normal speed whilst you are selecting a new playback position (whilst the user continues to move finger around the wheel). When the user stops moving for a second or so, playback will automatically resume at that position. To me, this is also how the Squeezebox should work by default out of the box, as a large user base would be most familiar with this functionality. Your suggestion is like (1) and (2) above merged together, but in my opinion the audio feedback is crucial for this type of seeking, otherwise it's pointless. >The implementation (called trick-mode internally) is pretty inefficient >and somewhat hit-and-miss. Recent improvements have made it somewhat >more reliable Seems to work flawlessly under SC7.0 beta for me, on both wireless players (SB2 and Transporter) that I have. I used to have a FF problem on my SB3, but to be honest I had loads of problems in general with wifi and the player rebooting, etc. It needs to go back for repair. The song scanner plugin in like (2) above, except that it by default it is awkward to navigate to, and return back to the now playing screen. This could be improved. >The implementation also has the problem that it affects many different parts >of the SC >software. It would be great to get rid of it. > True, but that's probably true for lots of other important bits of functionality - you can't just remove something because it hasn't been implemented well, and not replace it with something else. Eg. many people have unreliable wifi problems, but that doesn't mean that wifi should be disabled on all players! Can I suggest that you try to support both seeking methods, like an iPod does: 1. Press and hold FF to fast-forward through a song, similar to your suggestion, but with audio feedback. 2. Press and hold play to bring up a progress bar, where left/right buttons set the current playback position. Automatically resume playback when left/right are not pressed any more, or press play to resume. I suggest that the above could be the new default settings, but I would also like to see some configuration options to tweak the functionality (not sure whether the settings would be SqueezeCenter or player specific though). Could be advanced settings that most users would not need to go near. They would be a bit like setting the scroll rate in player display settings - most users won't need to tinker with the defaults. "Fast-Forward acceleration time": Select "<n> seconds", for the time FF is held down before ramping the playback speed up to the next multiplier. eg. default to "5 seconds". I'd like to have "0 seconds" mean manual acceleration, which would work like current functionality (each ff.hold would manually change up a gear). "Fast-Forward multipliers": Select a list of multipliers that fast-forward can go through: eg. default to x2, x5, x10, x20. Possibly some other option to decide what should be displayed when fast-forwarding in method (1): "No display", "Display progress bar" or "Display time/time remaining". Phil _______________________________________________ discuss mailing list discuss@lists.slimdevices.com http://lists.slimdevices.com/lists/listinfo/discuss
