Paul Louden <paulthen...@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
