From: sideral <asieoniezi_at_gmx.net>
Date: Tue, 04 Jan 2011 12:07:31 +0100

Paul Louden <paulthenerd_at_gmail.com> writes:
> On 12/26/2010 6:21 PM, sideral wrote:
>> Here's another thought. As I mentioned before, I view the autoresume
>> position as a per-track feature (hence, it has its place in the
>> database), whereas bookmarks take snapshots of playlists. Arguably,
>> what you want for your audiobooks is a bookmark, not a resume point
>> for each track. You shouldn't be using autoresume for your
>> audiobooks at all (that is, enable autoresume for your Podcasts
>> directory only).

> I don't see why "bookmarks" and "resume points" should be different in
> the end - there's a bookmark on stop function. It would make sense to
> replace the existing bookmark function with a better one that has the
> capability of the necessary automatic resuming behaviour.
>
> There really shouldn't be two separate ways of storing the last
> position in a track, and while that's necessary now, I think the goal
> should be to incorporate the two features into one, not make them
> explicitly separate, actually.

I agree with the sentiment that, ideally, resume positions in podcasts
(one per track) and audiobooks (one per album) should be stored and
recalled in the same way, and that using autoresume for one and
bookmarks for the other does not meet this requirement.

That said, I believe that both features have their merits, and it would
be hard to unify them under one umbrella:

* You can have as many bookmarks as you wish for each album or track,
  and they are portable across devices; but they clutter the filesystem,
  and require a separate user interface for selecting them, and it may
  not be obvious which bookmark was the last one if multiple exist.

* You have exactly one place where you last left off a track, and
  autoresume automatically remembers and recalls it for you when you
  start the track by whichever means you're used to (from DB, file
  browser, or playlist), without additional user intervention.

As you observed in an earlier message, autoresume works well for
podcasts, but falls a bit short for multi-track audiobooks, for two
reasons:

1. For audiobooks, automatic track change should never resume the next
   track even if this has been enabled for podcasts.

2. The user's natural way to play an audiobook (from the database or the
   file browser) should entail generating a playlist comprising (at
   least) the to-be-resumed track and the remaining audiobook tracks,
   and resume at the last playback position.

As food for thought, here's how the Clip's OF handles this, which I find
rather elegant: The OF solves Requirement 1 by requiring podcasts and
audiobooks to be in separate directories (/PODCASTS and /AUDIOBOOKS) and
enabling resume on automatic track change in one but not the other.
Requirement 2 is handled by remembering the last played track for each
podcast and audiobook album and highlighting the respective track when
entering the album in the DB browser [1].

I'd suggest to initially address Requirement 2 similarly to the OF by
allowing DB views to highlight the last-played track (we can already
record last-played time in DB).

I don't think we can address Requirement 1 in an automatic fashion
without either hard-coding directories (or genre tags, or track lengths)
or making them configurable, both of which people despise for different
reasons. I'd argue for making it configurable; barring that, I even
find it feasible to turn resume on automatic track change on and off
manually (I have put the setting on my quickscreen for easy access).

Finally, I'd like to point out one bit of inconsistency in the repeated
argument for basing autoresume on bookmarks or the existing
bookmark-on-stop function. The bookmarking system is powerful, but also
extremely complicated -- from a user's perspective, configuration-wise,
and implementation-wise. In my purely personal opinion, it is also
buggy as hell [2]. In comparison, the autoresume feature has a seamless
user experience, a trivial implementation, and arguably less complex
configuration.

Under the criteria you are using to judge the autoresume feature, the
bookmarking system should never have been accepted despite clearly being
useful to many people. Yet, people are proposing to make the
bookmarking system even more complex to cater for autoresume as an
additional use case. I claim that this would lead to more additional
complexity and less architectural integrity than what I'm proposing, and
also that no one is going to do that work.

sideral

Footnotes:
[1] and, IIRC, in the file browser on the Clip+ -- I have no way to
    check right now

[2] I've outlined some problems I've had with the bookmarking system in
    this comment: http://www.rockbox.org/tracker/task/11748#comment37597
Received on 2011-01-04