FF between files on Sansa Clip+

[jaurbik]

I just installed rockbox on my new sansa clip+.  This is my first attempt at using rockbox, so please forgive my ignorance.  

I really liked my old sansa clip, but i got relieved of it because I left it in my car.  I bought the clip+ but am unhappy with some of the updates, which is why I am trying out rockbox.  I mainly use it for listening to audio books, not music.  

One of the features on the clip, but not the clip+ was if you were playing several files, say, for example
lucky_1.mp3
lucky_2.mp3
lucky_3.mp3
lucky_4.mp3
lucky_5.mp3

and say one was 5 min into the file lucky_3.mp3, i could press the rewind button, and it would back up to the beginning of lucky_3, but then it would further rewind to the end of lucky_2.mp3, allowing you to stop at any point you want on the second file, not only the third file.  This is really nice when one realizes one has not been paying attention.  In the new clip, and in the rockbox version, it seems to get back to the last file one has to double press the rewind button, which takes one to the beginning of the previous file, not the end.

I am looking to be able to rewind like I was able to do with the original clip, if anyone can please tell me if there is a way to have this happen with rockbox, I would be much obliged.  

I have attempted to be as cleare as possible, but if I have failed in my objective, please let me know,, and I will try to reexplain.  

p.s. I relizes that I misnamed the post.  it should be Rewinding, not FF, though on the old clip, one was able to FF into the next track as well. 

[saratoga]

I can't think of any way to do this, but its possible theres something I'm forgetting. 

[[Saint]]

One of the features on the clip, but not the clip+ was if you were playing several files, say, for example
lucky_1.mp3
lucky_2.mp3
lucky_3.mp3
lucky_4.mp3
lucky_5.mp3

and say one was 5 min into the file lucky_3.mp3, i could press the rewind button, and it would back up to the beginning of lucky_3, but then it would further rewind to the end of lucky_2.mp3, allowing you to stop at any point you want on the second file, not only the third file.

I just tried this on Nano1G and Nano2G (both running r28611) and it definitely is advancing past the end of the track on >> but not <<...very odd.

I would suggest the fact that it does it whilst fast-forwarding is a bug though, or if it is intentional...it is very buggy.
Once the progressbar hits the end of the track while fast-forwarding, if you continue to hold the >> key it keeps advancing through multiple tracks and the WPS gives no indication that this is happening...
Instead of hitting the end of the track and stopping (which is my idea of what should happen personally).

I've no idea why << and >> should have different behaviours, it's quite odd.
I'm about 99% sure that it isn't some setting I'm missing somewhere.


[St.]

[Chronon]

For some reason I thought that setting "skip length" to a time increment would allow skipping across track boundaries but this doesn't seem to work as I thought.

[Llorean]

Well, if >> reached the end of the track and you kept holding it, I'd expect it to stop fast forwarding, then the track would end, then the next track would start, then Rockbox would say "hey, he's holding >>" and then start fast forwarding again.

So I wouldn't find it surprising that FF would take you "past the end" but it sounds like the WPS behaviour, at least, is buggy in relation to this.

Meanwhile in the same situation, if you rewound to << I would expect it'd stop, then just stay at 00:00 because you're still holding the button and it can't play.

This would then result in things that look like different behaviors for >> and <<, but really are the same behavior, "just keep doing it."

I'll agree though, it'd be nice to have the option between track boundaries stopping FF/RW or allowing it to continue past them (though this could create some awkwardness for acceleration / deceleration since it would decelerate more and more as you approached the end of the track).

[seani]

Well, if >> reached the end of the track and you kept holding it, I'd expect it to stop fast forwarding, then the track would end, then the next track would start, then Rockbox would say "hey, he's holding >>" and then start fast forwarding again.

So I wouldn't find it surprising that FF would take you "past the end" but it sounds like the WPS behaviour, at least, is buggy in relation to this.

Meanwhile in the same situation, if you rewound to << I would expect it'd stop, then just stay at 00:00 because you're still holding the button and it can't play.

This would then result in things that look like different behaviors for >> and <<, but really are the same behavior, "just keep doing it."

I'll agree though, it'd be nice to have the option between track boundaries stopping FF/RW or allowing it to continue past them (though this could create some awkwardness for acceleration / deceleration since it would decelerate more and more as you approached the end of the track).

I've been toying with an idea to change that behaviour (but done no code).

Rather than accelerating towards the end of the track, accelerate towards the midpoint between the current position and the end of the track, and then decelerate at the same rate when that midpoint is passed (but not coming to a stop, so not quite symmetrical).

A bit like a marble rolling into / out of a dip.

When a track boundary is "breached", reset the behaviour accel / decel based on the length of the newly entered track - no emergency stop and start.

[Llorean]

Doesn't it already accelerate toward a midpoint, then decelerate past it?

[[Saint]]

It seems to be some sort of fail with the acceleration?

I'm not sure...

Sometimes the whole "declerate when you're near the tracks end" thing works perfectly, and others it's possible for me to fast-forward off the end of track 1, hold for 2~3 seconds, then be in track 5-6-7ish.

I need to test it out more thoroughly when I have the time to, I tried it for 10 minutes or so whilst on my way home today and got *really* confused trying to find the "recipe".


[St.]

[seani]

Doesn't it already accelerate toward a midpoint, then decelerate past it?

I think it's been a long time since I even tried this - and it worked perfectly as you describe on my Clip+ for at least one podcast last night. I certainly should have checked before posting.