Rockbox mail archiveSubject: Re: Automatic multi-resume feature for podcasts and audiobooks (FS#11748)
Re: Automatic multi-resume feature for podcasts and audiobooks (FS#11748)
From: sideral <asieoniezi_at_gmx.net>
Date: Tue, 04 Jan 2011 10:11:25 +0100
Thomas Martitz <thomas.martitz_at_student.htw-berlin.de> writes:
> That's one thing I didn't understand (among others). If the resume
> position is not updated in the first 15s, why do you need to disable
> rewind to 0:00 (which is done to save the "precious resume
> point"). IIRC it wouldn't be updated anyway. On that note, I feel
> disabling rewind to 0:00 is a very (too) aggressive approach to save
> the resume.
| Thanks for sharing your idea! I'll see whether I can make it work.
| A simple implementation would be to regard rewind to 0:00 as a track
| stop + track restart, including all the statistics updates that
| entails (increase play count and elapsed play time, etc.). Does that
| sound reasonable?
I have managed to implement the behavior you proposed in my latest patch
set . I agree that this makes rewind-to-zero prevention mostly
> Additionally, and that's probably because it's not my use case, but I
> find the preciousness you put into a resume point exaggerated.
In a later message, Thomas writes:
> Although I'd like to add that resume points are also not stored within
> the *last* 15s of a song, because I usually have the "Skip to outro"
> setting enabled.
So you find your resume point a little more "precious" than you
originally thought, eh? ;-)
I understand the request; from a user's perspective, it would make
skipping forward work the same way as skipping backward: press Right
twice to skip to next track without losing the current playback
Unfortunately, this will be considerably harder to implement. In the
regular case (when not skipping to outro), the resume point needs to be
reset when automatic track change is in progress, whereas you suggest to
omit this update when the outro was reached by way of "skip to outro".
I have yet to figure out a robust way to discern the two cases.
 This particular patch is at:
Received on 2011-01-04