Thanks for your comments and questions, Paul and Thomas!
Thomas Martitz <thomas.martitz_at_student.htw-berlin.de> writes:
> On 13.12.2010 21:32, Paul Louden wrote:
>> Can someone point me to where 11748 was deeply discussed?
The deepest discussion has occurred in the tracker item itself:
And there has been a good discussion on IRC as well:
>> It looks like the patch currently adds an awful lot of options. Is
>> there a discussion of whether we want all this? It seems very
There hasn't been much discussion on this aspect yet, but it's a good
discussion to have, so here we go. :) You're correct, the configuration
is probably the most complex part of this whole feature.
>> I agree that auto-resume would be nice, but do we really need an
>> option to enable it as a possibility for when the next song is
>> reached in a playlist?
Yes, that feature seems rather essential to me. Losing the resume
position in a subsequent long-playing podcast or audiobook (by starting
playback from the start) is unacceptable.
The question is how to identify situations in which this behavior is
undesired, or more concretely, how to tell a podcast/audiobook from a
regular music album, which is where the resume customization comes into
>> Or specialized filters for which songs can or can't be resumed?
> I tend to agree, it looks vastly more complex to configure than
> needed, especially the filters.
I originally proposed (and still personally use) a simple heuristic
based on the length of the next track, but others suggested instead
inspecting the genre tag (e.g., "podcast") or the file path
(/PODCASTS/*). My patch offers all of these options, plus the option to
never resume the next track.
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
I agree that the configuration is somewhat complex. Especially the
time-based heuristic isn't self-explanatory enough. Nonetheless, I
propose to keep all these options available. (If pressed hard, I'd
first axe the next-track-length heuristic.)
Given this complexity, the user manual will have to have some good
explanations. I'll add the necessary manual changes once we've decided
what will be committed.
>> Is the option to prevent a user from skipping back to the beginning
>> of a file really related to auto-resume as it seems just a prevention
>> of track skipping?
> I also think the prevent track skip setting is unrelated.
No, this option does not prevent track skipping. It only prevents
rewinding the current track to its start (0:00) and thereby losing its
resume position. Track skipping in any direction is still possible --
in case of skipping backwards without first going to 0:00 of the current
BTW, I haven't received Paul's original reply. It's neither in the
mailing-list archive nor on Gmane, and I also haven't been Cc'd on it.
Has X-No-Archive been set on it?
I read (and post to) this mailing list through Gmane, as advertised on
the rockbox.org website. I may have missed more replies if more people
post to this list in the same way as Paul does.
Received on 2010-12-14