dev builds
themes manual
device status forums
mailing lists
IRC bugs
dev guide

Rockbox mail archive

Subject: Behaviour of PREV/NEXT when skip length > 0 and prevent track skipping is activated

Behaviour of PREV/NEXT when skip length > 0 and prevent track skipping is activated

From: Al Le <>
Date: Tue, 07 Apr 2009 22:14:42 +0200


Since not too long there are two playback settings: "skip length" and
"prevent track skipping".

I'd like to discuss the desired behaviour on pressing PREV or NEXT if
the first one is set to some length, say, 1 min, and the second one is
set to "yes."

As of now, the behaviour is as follows.

PREV: if the elapsed time is more than 1 min, you jump backward 1 min.
If the elapsed time is less than 1min, you jump to the start of the track.

NEXT: if the remaining time is more than 1min you jump 1 min forward. If
  the remaining time is less than 1 min, a beep is issued but the
position within the track is not changed.

Such behaviour has two drawbacks IMO:

1. It's not symmetric, i.e. PREV/NEXT behave not similar under similar

2. The action (and the amount of time skipped) taken upon a press may
heavily depend on the moment when the button was presse. For example, if
you press NEXT when 1:01 remain, you jump to 0:01 remaining time. But
two secons later, nothing would happen. Similarly with PREV: the amount
of time skipped dramatically depends on the moment when the button is

I'd prefer a solution that, while preventing changing the track, would
eliminate the above drawbacks.

We had some discussion on IRC (beginning at, and the best (IMHO)
solution we came up with was:

If you press PREV or NEXT and the amount of "remaining time in that
direction" is not significantly greater than the skip length, then the
jump is made not to the full step length but smaller.

For example, if the elapsed time is 1:20 and you press PREV, you jump 40
secs back (and not the full step of 1min). I.e. the closer you are to
the start/end of the track, the smaller becomes the jump. This would be
similar to how the seek speed decreases as the track start/end is

What do you think about it?

If the new behaviour is agreed upon, we'd have to define what "not
significantly greater" is and how the steps are reduced. As a source of
inspiration, seeking code could be used.

Your opinions are highly appreciated.

Received on 2009-04-07

Page template was last modified "Tue Sep 7 00:00:02 2021" The Rockbox Crew -- Privacy Policy