PDA

View Full Version : Fast forward/Rewind



thomsens
2007-06-20, 21:00
I'm sure it's been asked before, but is there any hope that the FF and RW will be improved on the Transporter/SB? As far as I'm concerned it's almost a broken implementation at this point. It's frustrating because it's the only thing I miss about my CD player. I'm using 6.5.2.

mswlogo
2007-06-20, 21:10
I totally agree but you can fix it.

One huge problem is, the Fast Forward and Rewind Buttons are double mapped.

They are mapped to Next Track / Previous Track AND Fast Forward and Rewind. Depending on how long and how many times you tap it.

You can remap these to different buttons.

Once seperated they work much better.

You do this by editing the Default.map file in the server\IR directory.

Also you cannot have transcoding active and the format must be native (e.g. FLAC) for fast forward to work.

It's still not as smooth and robust as a CD player but it's usable. As shipped it's unusable in my opinion too.

The fix above also makes Next Track/Previous track more robust too. I split them to the Volume Up down buttons because I use an external DAC. Then on my Harmony remote I map them correctly to SEPERATE FF/RW Next Track/Previous Track buttons.

MelonMonkey
2007-06-21, 09:18
One huge problem is, the Fast Forward and Rewind Buttons are double mapped.


Almost every product that features these abilities has them using the same buttons. This is a very basic control implementation from a usability perspective and something trivial from a timing/programming perspective as well. It's not part of any problem.

The FFWD and REW are just awkward implementations. They work as designed, but, like the original poster, I just wish they were designed to operate in the expected/common/standard method.

I'm certain the server-based nature of the product may include some latency, but I'd rather take my chances than be stuck with what exists now.

vrobin
2007-06-21, 09:31
+1 .

amey01
2007-06-21, 16:41
This has been asked before and is my pet peeve as well. In fact, it is my ONLY probelm with an otherwise fantastic product.

It is an advertised feature (and I would not have bought the Squeezebox if they had advertised that this simple feature that has been on every CD player (and WORKED ON EVERY CD PLAYER) since inception) didn't work.

I would think this has to be the highest priority as it is the ONLY "bug" [more like inadequacy] where any old CD payer surpasses the Squeezebox.

That also means having it work for non-native fomats. Nowhere is it advertised that you have to use FLAC or MP3 only if you want a fully functioning Squeezebox.

thomsens
2007-06-21, 20:49
This has been asked before and is my pet peeve as well. In fact, it is my ONLY probelm with an otherwise fantastic product.

It is an advertised feature (and I would not have bought the Squeezebox if they had advertised that this simple feature that has been on every CD player (and WORKED ON EVERY CD PLAYER) since inception) didn't work.

I would think this has to be the highest priority as it is the ONLY "bug" [more like inadequacy] where any old CD payer surpasses the Squeezebox.

That also means having it work for non-native fomats. Nowhere is it advertised that you have to use FLAC or MP3 only if you want a fully functioning Squeezebox.

I use both FLAC and MP3 and neither work well.

Skittler
2007-06-22, 01:04
mswlogo,
What have you found works well as an alternative mapping?

Could you post the relevant section of your .map file?

Thanks,
Dave

slimkid
2007-06-22, 05:36
+1 for everything said so far. However, in my experience, this is also a function of the included remote. I have mapped my NAD remote to control SB too (initially, for pure convenience) and have noticed that SB reacts much better to it, than to its original remote. At first, though it was about batteries, changed them and still, NAD remote with a year old batteries gets better responiveness than the original one with brand new batts. That includes FF/RW but also browsing and everything else that is mapped.

MelonMonkey
2007-06-22, 07:46
Let's keep some things clear so the issue doesn't get lost or misdirected.

Remote reception and strength is certainly a concern or source of potential issue from one product to the next and can be affected by a large number of variables. One handset in comparison to another for starters can use different amounts of power to their IR LEDs, a different number of LEDs, better filtered LEDs, etc.

The issue being discussed right now isn't about remote problems but a problem that as users we perceive with the current implementation of FFWD and REW.

We're not talking about a bug or transient issue, but the fundamental design difference between the SB and any normal CD player (and many/most other DAPs) with regards to forwarding and rewinding.

The current implementation while in playback mode (only tested with MP3 files):



Short press FFWD = skip to next track
Short press REW (1) = skip to start of track if elapsed track time > certain offset
Short press REW (2) = skip to previous track if elapsed track time < certain offset

Long press FFWD = activates an automatic 2x fast-forward mode (releasing the button leaves the player in this mode)
Long press REW = activates an automatic 2x fast-rewind mode (releasing the button leaves the player in this mode)


The 2x auto ffwd/rew sounds choppy and jumpy. You must be viewing the two smaller Now Playing modes to know what's going on. There's no FFWD/REW indicator when viewing in large font (this is also a big problem)

Repeating the long-press will switch over to 4x then 8x, 16x and 32x modes.

This is working similar to the FFWD and REW buttons on most DVD players.

Expected behavior is that of a CD player:



Short presses = same as they are now, they're correct.

Long press FFWD = playback increases rate to some fixed "x" and less choppiness should be present in the audio

Long press REW = playback increases reverse rate to some fixed "x" and less choppiness should be present in the audio


In both cases, releasing the FFWD/REW buttons should cause normal 1x forward playback to resume.

What this implementation loses is variable rate scanning. What it gains is a better connection to the user in terms of function. There is a more direct/tangible/immediate relationship between the pressing of buttons and the output of the player. It is the expected behavior for anyone that has ever used a late model tape player, CD player or many other DAP products.

If many people like the DVD-like scanning modes, then this could always be rolled into a configurable option. There are already so many I'm sure another one won't cause a huge issue. All these hundreds of options need to be hidden away for a more consumer interface anyway. And this mode set up as a default will definitely cause much less confusion when someone uses this product for the first time.

flipflip
2007-06-23, 10:15
Not sure if this might be interesting for other people who need ffw/rew (I need it in Podcasts and audio books):

http://oinkzwurgl.org/skipper

stuorguk
2007-06-23, 18:13
FF/REW is just not intuitive for me. I found remapping the Song Scanner plugin to the FF/REW buttons a better alternative, although it's not a perfect solution.

mswlogo
2007-06-23, 18:42
Almost every product that features these abilities has them using the same buttons. This is a very basic control implementation from a usability perspective and something trivial from a timing/programming perspective as well. It's not part of any problem.

The FFWD and REW are just awkward implementations. They work as designed, but, like the original poster, I just wish they were designed to operate in the expected/common/standard method.

I'm certain the server-based nature of the product may include some latency, but I'd rather take my chances than be stuck with what exists now.

I've never seen it.

Usually devices have 4 buttons for this.

<<,>> and <|,|> (These are Rew, FF, Next, Prev respectively)

The problem is you fumble around with FF and you don't hold it long enough and boom song gone (you execute a next track).

The whole thing of changing it's function based on how long you hold it is bad.

As far as remote strength goes, that has nothing to do with it and strength is excellent from stock remote. I can blast it off walls etc. Harmony works well too.

The basic edit I did in the map was to get rid of the HOLD thing and map the 4 functions to 4 buttons (with no holding). And map them to the standard 4 buttons found on any universal remote. >>,<<,|>,<|

After this it is fairly normal.

You have to pick 2 buttons to give up though. I used volume keys because I use an external DAC and Volume is locked any ways.

When you're done you get.

One tap on FF and it's fast forwarding instantly. Want it faster, Tap Tap. No Tap HOLD, Tap HOLD. You can't screw it up. And you can't accidently Tap to Slow or Fast and get unwanted behavior (i.e. the next song, grrrr).

Next Track is then just a tap too on a seperate button (you won't accidently start a FF if you hold it too long or too short). Again you won't accidently get unwanted behavior.

I think I posted MAP file once, don't have access at the moment to server.

It would be like making left mouse button function as left and right and only when you hold left long enough it performs a right click.

shaunm
2007-06-25, 07:24
My problem with the FF/Rew functioanility is that only the Next Track, Start of Current and Previous Track functions work.

I can scan a x2, x4 by holding the button down, but I cannot play from the middle of the track. If I hit pause, it pauses, hit pauses again and nothing happens.

If I hit play, when scanning, nothing happens.

If I pause during scanning, then hit play, it plays from the beginning of the track.