From: sideral <asieoniezi_at_gmx.net>
Date: Thu, 16 Dec 2010 11:59:05 +0100

Paul Louden <paulthenerd_at_gmail.com> writes:
> I really don't want this to descend into a "his idea vs my idea" kind
> of situation. What I'd like us to do is try to decide as a group what
> sort of playback situations auto-resume should address (playlist full
> of half complete files, primarily individual files or single files in
> a list of related files that shouldn't be resumed, etc) and how we
> want to address them (highly configurable, "one size fits all" or
> somewhere in between) etc.
>
> My personal preference is this:

Paul,

I strongly suspect it won't be possible to come to a group decision on a
feature set without also allowing some level of configurability. You've
stated what your preferences are. Unsurprisingly, my requirements
differ significantly from your preferences, and others may still have
other needs.

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.

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.

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.

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.

> I would like Rockbox to attempt to resume any file that is the first
> file you select to play back. Basically, when I click "select" or
> "right" on a music file (button names may vary by player) that file
> should attempt to resume, but nothing else in the auto-generated
> playlist should.

Very well. The behavior you want is already implemented. I agree on
making this the default behavior, without removing the alternative
behaviors (configurable autoresume on automatic track change).

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

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

Rockbox currently does not expose the concept of ``completed
podcast/audiobook,'' although with my patch it is possible to create a
database view that selectively includes or excludes completed files,
taking advantage of autoresume resetting the resume offset to 0 for
completed files, and (un)selecting only files with offset == 0 and
playcount > 0. 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.

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

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

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

sideral
Received on 2010-12-16