From: Paul Louden <paulthenerd_at_gmail.com>
Date: Thu, 16 Dec 2010 10:24:07 -0600

On 12/16/2010 4:59 AM, sideral wrote:
>
> Nonetheless, under the premise of simplifying configuration you are
> pushing to remove two features I regard as important (prevent skip to
> 0:00; autoresume on automatic track change), without allowing them to be
> enabled by way of configuration.

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)
and why are the alternatives offered elsewhere in this thread as means
of not losing a resume position also not meeting your needs?

As for resume on automatic track change, is this something you really
feel is a widespread use case, or just something important to you? 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?

> I respectfully disagree. The result would not meet my requirement of a
> seamless autoresume feature. My goals are to support complex listening
> habits without additional user intervention, and to provide a simple way
> for never accidently losing a resume point for a user-defined set of
> files. Deriding this requirement as an edge case is not going to get us
> forward.

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. Meanwhile I
can't have a playlist that isn't auto resumed, then move to a playlist
that is without reconfiguring Rockbox, 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. It could be argued that mine
supports *more* complex listening habits, while requiring less
configuration and less re-configuration.

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.

> From this thread, it is pretty clear that ``one size fits all, no
> configuration needed'' will not be the consensus. Another outcome is
> that, apparently, autoresume cannot be made as simple as you may have
> anticipated. Therefore, some level of complexity is warranted for its
> configuration.

This is true, but finding out what level of complexity is necessary is
the goal here. I also don't agree that we can come to the conclusion
that it can't be this simple yet - we still don't even have a list of
clear expectations from it, even from you.

> 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. :^) That is not
> to say that each feature shouldn't be easily discoverable and shouldn't
> come with sane defaults.

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. As I've said, I think my suggestion, when explored, offers
very nearly the full power of yours. In fact, the only thing I can think
of that you can't do with mine but can with yours is to skip back and
forth between tracks with resume points. But if "queue with resume" were
paired with "insert with resume" this too would be a non-issue. What I'm
arguing against is over-engineering a feature. If it can do the same
list of things, but present itself in a much simpler way, why include
the more complex way and create intentional confusion. This is why we
need the list of things for what it should do - so that we can determine
if it does do the same list, or if any of those are unneeded.

As for the intelligence level of the user base - having run our forum
support for several years in the past, I can assure you that if you
provide anything that a user can mistake as a bug, they will. Automated
behaviour falls squarely into this category. It's not a reason to avoid
this - as I said I don't think Rockbox should be dumbed down. But never,
ever assume that a user will not be intimidated or confused by a
feature, or misunderstand them. The sheer number of users out there, and
the sheer variety of backgrounds nearly insures that there's at least
one user who will both misunderstand it, misapply it, and ask for help
in a painful way. It's a fact of life.



>
>> 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? 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.

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. "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?"
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. The third one seems most obvious but the language you described
it with makes it unclear if it's one of the other two.


>> (possibly this should be treated as an explicit message from the user
>> that the file is complete, as this is what it would mean if I ever
>> intentionally skipped tracks on the chapter I've selected in an audio
>> book, or skip to the next podcast in a series).
> 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.

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. 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).

> If needed, we could indeed add a feature that marks
> tracks in this way as ``completed''; but is shouldn't be mapped to the
> skip button.

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." I still strongly believe "stop" should save
resume points, but "next" should either fail to update them or reset them.

>> Some additional features which could add flexibility:
> ...and complexity. :-) I am not generally against adding new features,
> but I ask to please respect the needs of the developers of the present
> patch as well.
>
>> 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?

>> A "queue for resuming" option in the context menu that queues up a
>> song in such a way that when it is reached in the playlist it would
>> resume. This would allow most of the functionality of in-playlist
>> resumes without it ever being an "implicit" behaviour that happens to
>> users rather than happening when users explicitly ask for it,
> I do not agree that this is better than the present feature for
> autoresuming on automatic track change. First, it requires a special
> navigation to enable autoresume for queued tracks, which is opposite to
> my goal of enabling autoresume seamlessly and independently from the way
> a file is selected (from bookmark, file browser, or database). Second,
> it requires user intervention each time a file is selected, rather than
> just once at configuration time to select the set of files to which
> autoresume on automatic track change should apply.


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, and does not allow it to be
conditionally used within a single playlist. 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.
Your method has many options, but is inflexible to begin with. 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 and improving the total ways in which
the feature can be used?


>> and allows a mix of multi-part long audio and collections of single
>> incompletely listened to files without one or the other not working
>> with the feature.
> I do not fully understand what you mean here, but I believe this is
> already possible with the present patch if a set of autoresumable files
> has been configured.

With my method, can have four files that are all the same length,
filetype, genre, and folder. Two of them will auto-resume within the
playlist, and two will not. With your patch automatic conditions will
likely flag either all of them auto-resumable or all of them not.
Received on 2010-12-16