From: sideral <asieoniezi_at_gmx.net>
Date: Sat, 18 Dec 2010 00:10:20 +0100

Paul Louden <paulthenerd_at_gmail.com> writes:
> On 12/16/2010 4:59 AM, sideral wrote:
>> Paul Louden <paulthenerd_at_gmail.com> writes:

> Please, rather than simply disagreeing, let's talk about how your
> needs aren't met by this. "Party mode" will guarantee a resume point
> is never lost already. "Queue for resume" will allow a playlist of
> files all to be auto resumed without any additional user
> intervention. Both of these meet your description of your needs so
> far, so it's impossible for further discussion to happen without
> extended clarification.
>
> This is why I want to talk about specific needs. Since you aren't
> explaining why mine is unacceptable, and in a purely literal sense it
> allows one to create a playback situation that once started will
> behave in a very similar way in terms of allowing resumable tracks to
> exist in a playlist, it's hard to understand why it's unacceptable.

First, let me tone down that statement a bit: I never said that your
proposal would be unacceptable. I merely stated that it wouldn't fit my
requirements. It's true that I should have stated my requirements more
clearly in the first place, and I'll attempt to clarify them in this
post.

It's also true that, through the means you've proposed, it would be
possible to arrive at the same playback situation. However, more key
presses would be needed to get there, and certain features could not be
used any more without loosing the current resume point, including
skipping back and forth among the tracks of the playlist.

Here's my high-level goals that, in my view, are not accomplished by
your proposed feature:

First, I'd like to not only be able to resume every track at the point
at which I last interrupted it, but also to force resume to happen in
all cases automatically independent of how I arrived at playing back
that track. To ensure preservation of the resume position, I know of no
other way than preventing a resumable track from ever restarting at
0:00, and this is what the two features I implemented come down to.

Second, I'd like to enable autoresume to work totally seamlessly without
forcing users to change his use model or learn any new menu function.
Users should be able queue up their tracks in whichever way they're used
to and they find most convenient.

*Sigh* oooookay *taking a deep breath*, let's go on to the 10 features
or so we disagree on. Readers who are easily demoralized are encouraged
to skip straight to the happy ending, where we actually agree on
something. SPOILER ALERT: It all comes down to configurability for the
default behavior. (And, of course, my feature is better than yours. ;-)

> You mention that "prevent skip to 0:00" is important to you. Why are
> the existing means of preventing skipping unacceptable (what don't
> they do)

I apologize; I assumed I had made myself clear on that point in an
earlier message.

The existing skipping-prevention features do not work for me because my
goal actually is not losing the resume position, rather than preventing
skipping. In fact, I'd hate to loose the ability to jump between tracks
(party mode) or even to use any other Rockbox feature (UI lock).

Therefore, I added an option to disable solely the feature that erases
the current playback offset: the rewind to 0:00 function. If enabled, a
short Left click (for all resumable files, or optionally for all files)
skips back to the previous track (after storing the current playback
position as the current track's resume offset).

I realize that this function is not for everyone; it represents a
tradeoff a user has to make between a useful feature (rewind to 0:00)
and the desire to never accidentally lose a resume position. Hence, it
is configurable.

> and why are the alternatives offered elsewhere in this thread as means
> of not losing a resume position also not meeting your needs?

Which other means are you referring to, and in which way do they
preserve the resume offset when a user presses Left?

> As for resume on automatic track change, is this something you really
> feel is a widespread use case, or just something important to you?

Yes, I do feel this is an important use case. Many users simply cannot
stand listening to the same contents twice and are willing to go out of
their way to make sure that never happens.

FWIW, the Sansa Clip{V2,+} firmware handles podcasts in this way as
well.

> Why is a compromise such as the "queue for resuming" that allows the
> configuration to remain simple, but gives you most of that
> functionality unacceptable?

In short, I think that making resume on automatic track change
configurable with a simple yes/no option is the better compromise.

Long answer: My express goal was to save the user from having to do
extra work each time he or she selects a track. A separate "queue for
resuming" feature makes the user jump through a couple of extra hoops,
which makes the process error-prone and confusing: Users must not forget
to use this extra feature, otherwise they will lose the resume position
for the next track. Also, the Insert menu already is quite confusing
and overloaded, and adding another option there will make it even worse.

As a minor point, I'd like to point out that in your proposal, resume on
track change would be a property of the playlist, whereas in mine, it is
always a property of the track, which arguably is easier to reason about
for both users and developers, and is easier to implement. (One
possible simplification of your proposal would be to reset each tracks
resume point immediately when queued unless it was queued for resume.)

Again, I guess this comes down to preferences. Conceivably, we could
offer both your and my feature. Or we could add a setting that makes
"queue for resuming" the default insert option.

> Meanwhile I can't have a playlist that isn't auto resumed, then move
> to a playlist that is without reconfiguring Rockbox,

You seem to imply that you'd need to reconfigure Rockbox each time you
move between those two playlists. That's not true: You can configure
once which files should be assumed to be autoresumable upon track
change.

> nor can I have a mixed playlist of resume and non-resume where I can
> explicitly decide which is which under your system, but can under
> mine.

Correct.

> It could be argued that mine supports *more* complex listening
> habits, while requiring less configuration and less re-configuration.

This may be true, although I do not know a person who has this
particular listening habit, whereas I do know people who have the one I
described. :)

>>> Resume state is only saved if I stop playback or the player triggers
>>> an automatic stop by something forcing playback to stop. If I skip
>>> to the next track in a playlist, that does not result in the
>>> updating of the resume point
>>
>> As this breaks the "interrupt for now, resume later" use case, I
>> would not want to lose the resume point when skipping (with the
>> exception of not updating the resume point when skipping within the
>> first 15 seconds of elapsed play time, as outlined in my reply to
>> Dave Hooper).
>
> Why can't you stop, and select another file?

It is less convenient and easy to forget, risking the precious new
resume point I've arrived at.

> I don't believe every possible use case needs to be addressed, and
> this one creates a disadvantage for what I see as the more common use
> case, which would be people skipping for navigation rather than to
> skip back and forth between multiple incomplete tracks. The one thing
> we should strive to avoid is to create a problem for the common use
> case by attempting to support less common ones.

I also think that we don't have to address every possible use case.

>> I don't see what you lose by having the resume point updated in this
>> case.
>
> I dislike having a file I listened to, seeked in, listened to again,
> seeked in, listened to again, discovered I'd completed, and pressed
> "next track" now resume near the end rather than starting at the
> beginning.

If you've completed this track (assuming its a podcast/audiobook), why
do you still care about its resume position? That doesn't seem to be a
very common use case to me. :)

> If the only way for a file to exist without a resume point is for it
> to reach the end without skipping, this is a problem. I didn't mean
> "completed" so much as "in a position so that running it again will
> start at the beginning."

It's not the only way. The typical way is to define only a subset of
files as autoresumable. (In your particular case, you could configure
your Podcasts and Audiobooks folders to contain resumable files.)

> I still strongly believe "stop" should save resume points, but "next"
> should either fail to update them or reset them.

Again, if needed, we could add a function "mark as played" or "reset
resume position". I disagree that this should be a side effect of
pressing Right (Next).

> As well, not storing a resume point in the first 15 seconds (if resume
> points are going to be stored) is another one of those automated
> behaviours.

I claim that Rockbox offers a lot of these heuristics (many of them
hardcoded) for pure convenience. For example, you cannot I use the Left
button to rewind to 0:00 when you're in the first few seconds of the
file.

> "Why can't I open a file, seek to the time I want, then move to the
> next file, so that I can prepare its resume point for later?"

Actually you can, because of the answer to the next question:

> Also, does this mean "15 seconds of time spent with the file as now
> playing" or "if the resume point's in the first 15 seconds" or "if the
> resume point is within 15 seconds of where the file was last resumed?"
> None of these are ideal in my opinion, though obviously for different
> reasons.

I agree with the observation in the last sentence. This is a heuristic
after all -- but the cases in which it hurts hopefully are rather rare.

> The third one seems most obvious but the language you described it
> with makes it unclear if it's one of the other two.

I actually didn't describe it very well in earlier messages. The
correct answer for the present patch is the second: The resume point is
not updated if it is in the first 15 seconds of the track.

[ On queue for resume: ]
> For many use cases, a playlist is a single work composed of smaller
> bits, rather than several independent podcasts or whatever and in
> those cases it would make little to no sense to store independent
> resume points.

If the tracks are short, then typically they will be played till the
end, and only the single one that was interrupted will have a resume
point. Also, you can disable resuming for these collections of small
tracks altogether (as you would for music in general) or disable resume
on automatic track change globally.

I think you overestimate the confusion created by the autogenerated
resume points. I really do listen to a lot of music, podcasts, and
audiobooks, and I use the really simple track-length heuristic for
deciding when to resume on track change, and otherwise have autoresume
enabled globally. I have yet to encounter the first occasion where the
feature does the wrong thing or gets into my way.

> This is why explicit behaviour is to a degree better - if you have
> several podcasts in a folder, and want to change which one you're
> listening too you can stop to update the resume point, select the next
> one, and begin. Meanwhile this allows one to explicitly decide when
> to, and when not to, update the resume point. This allows a degree of
> increased flexibility with only a slight overall increase in
> complexity for the user (something I should think you would agree with
> since you seem strongly in favour of supporting all listening habits).

Yes, we can always add features to cater for emerging listening habits.
I never objected to increased flexibility. I just want to be able to
set up the default behavior with the constraints I outlined at the
outset of this posting.

> You can queue whole folders. And it prevents auto-resume from being
> applied to files where it shouldn't, which is the goal. Your current
> method requires someone who wishes to use auto-resume to take action
> every time they don't with to use it,

Whereas your method requires someone who wishes to use autoresume to
take action every single time they *do* wish to use it. My method wins.
:-)

> and does not allow it to be conditionally used within a single
> playlist.

Correct. Fortunately, your point is mostly moot because users can set
up the conditions on which to autoresume files globally, once and for
all, rather than having to think about them every time they queue up
some tracks.

I dispute that the flexibility you envision constitutes the more
frequent use case, but am not opposed to add more features later
enabling it.

> This instead requires the person who does wish to use it *only* to
> take action when they wish to use it conditionally (when they wish to
> use it for all files in a folder or playlist there's no additional
> navigation require other than a small number of button presses once to
> initiate playback). There really isn't a significant increase, and
> it's only for the user of the feature while decreasing the possibility
> the feature can get in the way of non-users.

The feature will never get in the way of nonusers because it defaults to
off. Once autoresume has been enabled, resume on automatic track change
will never get in the way of nonusers either, because that feature also
defaults to off.

> Your method has many options, but is inflexible to begin with.

Another way to put it is that my method has been "streamlined" for the
major use cases. :-)

> This method allows the user more choice by removing the automation,
> and costs 2 or 3 extra keystrokes per song in a mixed list, and 2 or 3
> extra keystrokes per list in a non-mixed list. Is 2-3 extra keystrokes
> really too much to ask for reducing to a large degree the number of
> configuration options necessary

I convinced that the answer is: Yes, that's too much. The extra
keystrokes needed every single time are an invitation for making errors,
putting the user's precious resume positions at risk.

> and improving the total ways in which the feature can be used?

I'm not opposed to making the feature more flexible, under the
conditions mentioned above.

[ On additional features: ]
>>> A "return to resume point" option in the context menu that, before a
>>> file ends, returns to the resume point the file was started from.
>>>
>>> A "stop without saving resume point" option in the context menu that
>>> stops playback without generating a resume point.
>> What would be the use cases for these features?
>
> They're additions to the way I would have the feature work. They serve
> to offer the ability to avoid losing the resume point accidentally as
> easily (if for example you seek rather than skipping). As well, I
> think the second one is rather explicit - can you conceive of no case
> where one might not want a resume point added to a file?

Yes, these might be good additions to any of the feature sets we've been
proposing -- in a second step.

>> Also, I am against dumbing down Rockbox in any way. I regard
>> Rockbox's level of configurability as a major strength, and I suspect
>> that the typical Rockbox user, having taken the hurdle of actually
>> installing the software, can be regarded as above-average
>> intelligent. :^) [...]
>
> Here I think I can safely say I have the knowledge and experience to
> disagree fully. First, I'm not arguing for dumbing down, but rather
> for streamlining. [...]

OK, I totally buy your argument here. So let's make Rockbox really
smart rather than dumb. :)

sideral
Received on 2010-12-18