View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0011153 | MMW v4 | Player | public | 2013-08-14 17:03 | 2013-08-29 23:27 |
| Reporter | lowlander | Assigned To | |||
| Priority | high | Severity | minor | Reproducibility | always |
| Status | closed | Resolution | fixed | ||
| Product Version | 4.1 | ||||
| Target Version | 4.1 | Fixed in Version | 4.1 | ||
| Summary | 0011153: Ability to easily restart playback of a bookmarked track | ||||
| Description | Currently if bookmarking starts playback at bookmarked time forcing the user to scroll to beginning of file. Some users may prefer to have bookmarking enabled (in case you stop playback in middle of file), but still be able to play from beginning easily (like if you stop playback during end credits). An optional prompt at beginning of playback to start at beginning or resume playback would be useful. | ||||
| Steps To Reproduce | Alternative options: 1) Option to ignore bookmarking at x% from beginning and end of file. 2) Option to reset bookmark (manually changing Played# does this, but is a hidden method). | ||||
| Additional Information | http://www.mediamonkey.com/forum/viewtopic.php?p=372635#p372635 | ||||
| Tags | No tags attached. | ||||
| Fixed in build | 1654 | ||||
| related to | 0002680 | resolved | Ludek | Change algorithm of increasing Playcount |
| related to | 0010856 | closed | Ludek | Hitting 'Pause' button doesn't bookmark |
| related to | 0004961 | closed | petr | 'Back' button should return to the beginning of the currently playing track |
| related to | 0011155 | closed | peke | Play menu: Separate Play and Pause should be available beside Play/Pause |
|
|
I do not think it would be too usable. But you are right there is bug in handling Bookmarked tracks. The solution would be that on playing Bookmark enabled track Pressing PLAY (Not Play/Pause) would reset playback to beginning like it is done for all normal tracks. I'll open new bug as Play and Pause should be available in Play Menu to beside Play/Pause Option |
|
|
I think Peke's idea (press play to initiate playback from the beginning) makes a lot of sense. But unfortunately, it's not really practical, since most skins don't have a Play button in the UI (only Play/Pause). I like Martin's idea of a prompt at startup to reset the bookmark, though I don't think we need to make this configurable, but it doesn't fully address the problems raised in the forum--the fact that if 97% of a movie is played, that MM still considers it unplayed and doesn't reset the bookmark, so we'd probably also want to implement the suggested option of using a % playback for audiobooks/movies. i.e.: a) review the algorithm for when a track is considered played. e.g. if a track is paused after > 97% has been been played, then the track counter should update (but the bookmark should not be deleted)--my understanding from 0002680 is that the counter doesn't operate on a % basis, because of problems that this caused with audiobooks, but I think that audiobooks and movies can use % as a metric for whether to update the play counter. b) if the user presses pause after the play counter has been updated, a bookmark should still be maintained, BUT, when playback resumes a 10-second timed popup should appear asking: Play: <Title> (o) Resume from bookmark (hh:mm:ss) ( ) Start from beginning [OK] |
|
|
Peke's comment relates mainly to 0011155, so I'll address it there. |
|
|
I really don't think that PLAY button should restart bookmark, this would be quite unexpected and non-standard. Lets look on the PREV button behaviour that currently does the job fine, lets look on these scenarios what can happen when pressing PREV button when a bookmarked track is being played: SAVED = new bookmark after pressing the PREV is saved PRESERVED = old bookmark is preserved - pressing PREV, wait 5 seconds, press STOP => SAVED - expected - pressing PREV, immediatelly press STOP => PRESERVED - expected - pressing PREV, PREV => switched to the previous track and PRESERVED - expected - pressing PREV, wait 5 seconds, close MM => SAVED - expected - pressing PREV, immediatelly close MM => PRESERVED - expected - pressing PREV, wait 5 seconds, PAUSE => SAVED - expected - pressing PREV, immediatelly PAUSE => PRESERVED - expected But Peke is right (showing at 2:00 of his video) that there is one scenario that doesn't work as expected: - pressing PREV, wait 5 seconds, press PLAY => PRESERVED - unexpected !!! i.e. when track is being played, pressing PLAY (via Play menu or playlist window) changes the playing position to the last bookmark, this is bug. Note also that bookmarked position rewinds 5 seconds when replaying, this is so that user can keep context, i.e. pressing STOP at 3:35 saves 3:35, but on second play it starts playing from 3:30 (user can hear the last sentense before bookmark) |
|
|
Actually I have to correct myself a little 1) Bookmarked track is not starting 5 seconds, but 3 seconds earlier (so that a short part is repeated again) 2) PRESERVED = old bookmark is preserved Incorrect position is preserved sometimes, if user - plays video and press stop at 3:35 then the bookmark is saved (expected) - plays video again, let it play for another minute (4:45) and press PREV and immediatelly STOP => 3:35 is preserved although 4:45 should be in fact preserved This is bug that I see. |
|
|
The bugs reported in my last two notes above are fixed in build 1654. |
|
|
1) Any interruption (asking user to resume or start from beginning) should be optional. I've seen this in Android Apps and it is a useful feature, but it can be disabled. It would seriously hinder users who want to watch some videos if they couldn't disable the option (Confirmations). 2) The prompt (asking user to resume or start from beginning) is very useful for some though. It can be very useful in multi-user environments as well as users with mixed-video environments. 3) The option to limit bookmarking from happening if x% from beginning and y% from end (separate options) would also be really useful to some users. MediaMonkey users are a diverse group representing many use-cases of MediaMonkey and implementing both features as options would greatly improve MediaMonkey in the different use-cases. |
|
|
Verified current implementation in 1656 |
