dev builds
themes manual
device status forums
mailing lists
IRC bugs
dev guide

Rockbox mail archive

Subject: Re: Automatic multi-resume feature for podcasts and audiobooks (FS#11748)

Re: Automatic multi-resume feature for podcasts and audiobooks (FS#11748)

From: sideral <>
Date: Wed, 15 Dec 2010 10:30:58 +0100

Hi Paul,

Thank you for your response! I much appreciate the rigor with which you
scrutinize my proposed new feature.

Paul Louden <> writes:
> 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 settings.

I fully agree with this goal.

[ On autoresuming the next track on automatic track change: ]
> 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?

Yes, there is an important common use case: It's listening to the
remainder of all (potentially previously interrupted) podcasts queued up
in a dynamic or static playlist. (Besides, as I mentioned in my
previous message, it prevents losing any resume points in subsequent
tracks that a user may still care about.)

> On 12/14/2010 4:29 AM, sideral wrote:
>> 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 configuration.
> 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

Agreed so far.

> or a 1 hour podcast.

Here we disagree. I absolutely do not want to listen to a previously
interrupted podcast from the start (and from what I've gleaned from the
forum and heard from other users, many podcast listeners feel this way).

BTW, my requirement is consistent with how the Sansa Clip{,V2,+}
firmware treats resumable files. The clip regards all files in the
(factory-created) /PODCASTS and /AUDIOBOOKS directories as resumable.

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

In principle I agree.

The problem is slightly less severe because the autoresume feature as a
whole defaults to off, so there will be no surprising mid-track resumes
unless the user turns the feature on globally. Also, if we come up with
a better default for which tracks are resumable (such as only files
under /PODCASTS), the feature won't be as surprising any more.

Alternatively, I'd also be fine with defaulting to "never resume on
automatic track change" if there's an option to enable it.

[ On rewind-to-start prevention: ]
> 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.

I see what you mean. There are really two different questions:

First, is the new feature required at all, or is it really redundant
with an existing feature that totally prevents track skipping / fast
forward / fast reverse?

And second, if the feature is needed, should it be specific to the
autoresume feature, that is, dependent on autoresume being turned on and
configurable in the autoresume submenu?

To answer the first question: I think that there's an important
conceptual difference between the existing track-skipping-prevention
features and the new one: The new feature does not prevent track
skipping. Rather, it _enables_ track skipping (backwards) to work
without losing the current track's resume position. As such, the
feature actually encourages users to use track skipping, rather than
preventing them from using track skipping. It works by disabling the
function to rewind to the start of the current track. Pressing the
rewind key once now immediately skips back to the previous track
(instead of first rewinding the current track to 0:00). This feature is
desirable when inspecting a long playlist full of podcasts and finding a
good one to listen to.

As to the second question, I have no strong opinion. I personally think
preventing rewind-to-start is pretty useless unless the current track is
resumable, but other users may specifically want to enable it for all
tracks, maybe even if they do not use autoresume at all. If that were
the case, the config option should move to another menu (the playback
menu?); otherwise, I think it logically belongs to the autoresume menu.

Received on 2010-12-15

Page template was last modified "Tue Sep 7 00:00:02 2021" The Rockbox Crew -- Privacy Policy