On 12/14/2010 4:29 AM, sideral wrote:
> There hasn't been much discussion on this aspect yet, but it's a good
> discussion to have, so here we go. :) You're correct, the configuration
> is probably the most complex part of this whole feature.
Generally speaking the ideal is to add as few new options or settings as
possible, so we should be looking at how to make this as powerful as
possible and/or offer the full functionality with a minimum of confusing
> Yes, that feature seems rather essential to me. Losing the resume
> position in a subsequent long-playing podcast or audiobook (by starting
> playback from the start) is unacceptable.
> The question is how to identify situations in which this behavior is
> undesired, or more concretely, how to tell a podcast/audiobook from a
> regular music album, which is where the resume customization comes into
Is there a common use case for having a playlist of multiple
incompletely listened to files that all need resuming from midpoints?
Could you describe why this commonly happens?
I'm not saying it's impossible, just that I've never been in a situation
where I've wanted to queue multiple files more than one of which I
didn't want to play from the start. It might better help me understand
if you could describe the situation in which this is useful.
> Right now the next-track resume behavior defaults to "all resumable
> tracks", and by default all tracks are resumable. Arguably, this
> default is worse than any of the other options, but it's the only option
> that both never loses resume positions and doesn't require further user
It seems the opposite should be true - the default should never be for
Rockbox to seem to move playback position in a way that is unexpected to
the user. I would say the best default would be "resume when they click
on a file, but never if the file is entered by playlist position
moving." I would imagine a very significant majority of users would find
it surprising if Rockbox skipped over 30% of the second track in their
playlist because that's where they'd hit stop in it last time they'd
tried playing it whether that track was a 5 minute song or a 1 hour
podcast. If the option of having it able to resume multiple entries in a
playlist is necessary, it should be off by default (in my opinion)
because this is what could be considered very unexpected behavior. I
feel it's more important not to seem buggy (as skipping around seemingly
by surprise in tracks very well would to users) than to risk losing
resume position for users that won't be aware of the
resume-within-playlist feature (as if they're aware of it, they'll know
it needs turning on, and thus won't lose their position, so they're
protected as well).
> Given this complexity, the user manual will have to have some good
> explanations. I'll add the necessary manual changes once we've decided
> what will be committed.
I would say good explanations are essential at this point to facilitate
the discussion of which settings are necessary and which aren't.
>>> Is the option to prevent a user from skipping back to the beginning
>>> of a file really related to auto-resume as it seems just a prevention
>>> of track skipping?
>> I also think the prevent track skip setting is unrelated.
> No, this option does not prevent track skipping. It only prevents
> rewinding the current track to its start (0:00) and thereby losing its
> resume position. Track skipping in any direction is still possible --
> in case of skipping backwards without first going to 0:00 of the current
The point was more that being unable to accidentally lose the current
position in the track (by skipping back only or by skipping forward or
back) is a functionality that could easily be considered independent of
whether or not to resume tracks, and so is something that might not
belong exclusively within the auto-resume menus. It's very easily a
feature someone not using auto resume may want, and probably should be
considered independently of the auto-resume feature rather than treated
as an auto-resume setting. It's currently possible for a user to lock
the buttons or enable "party mode" to prevent accidental loss of the
position within the current song, so this may be an example of an option
that while offering very slightly different functionality, isn't really
necessary to further confuse the use of things.
Received on 2010-12-14