View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0012893 | MMA | Now Playing | public | 2015-10-13 21:59 | 2015-10-15 22:04 |
| Reporter | rusty | Assigned To | |||
| Priority | urgent | Severity | major | Reproducibility | always |
| Status | closed | Resolution | fixed | ||
| Product Version | 1.1.3 | ||||
| Target Version | 1.1.3 | Fixed in Version | 1.1.3 | ||
| Summary | 0012893: Bookmarking doesn't work correctly in Now Playing (regression) | ||||
| Description | If the user plays a podcast or audiobook with MM 1.1.3, then on Pause or Stop, the track is correctly bookmarked. If the user then: a) plays the track via the Track Browser: it resumes correctly at the bookmarked location b) plays the track via Now Playing: it restarts!! This is particularly problematic for users playing via their car. When they turn off the vehicle and subsequently restart, MMA restarts from the beginning (since bluetooth is using scenario b) above). | ||||
| Additional Information | Reported at: http://www.mediamonkey.com/forum/viewtopic.php?f=21&t=81509 | ||||
| Tags | No tags attached. | ||||
| Fixed in build | 486 | ||||
|
|
I can't replicate in this way, but I guess it has different cause. Current implementation: On Pause action - track is bookmarked On Stop action - track is reset to begin. How we can receive "Stop" action: 1) from remote device (BT with stop button) 2) from Playback Notification but there is one inconsistency now. After 1 minute inactivity, PlaybackService is destroyed for saving battery and new Playback Notification (called PasiveNotification) is shown depending on the time, set in Options. And there is inconsistency, because when user use "Stop" action earlier than 1 min then "Stop" action reset playbak to begin(and stop PlaybackService) else, after 1 min, "Stop" action just hide PasiveNotification. So I guess that maybe "Stop" action was used in different times to induce this issue. To remove this inconsistency we can change "Stop" action of PassiveNotificaton to "Cross" action, which just hide PassiveNotificaton. On other hand, reports from users mean that reset to begin on "Stop" action is not required. So I suggest remove "reset to begin" on "Stop" action. |
|
|
I think that the issue may be unrelated to the timer since when I set the timer to 30s, the bug occurs whether I stop playback prior or after 1m, and re-open the app 1m later. Here's an example of how this can work via the 'Stop' button in the Playback Notification: 1 Play a podcast A, episode 1 2 Open the notifications bar and press 'Stop' 3 Close the notifications bar OR wait for the timer to expire and turn the device back on -->The Now Playing AA window shows Podcast A episode 1 at 0s (pressing play will cause the podcast to restart) 4 Press 'android back' button to go back to the Podcasts view that shows podcast A --> All episodes display, and the bookmark bar shows that episode one has been partially played (pressing play will resume at the correct location) The problem users are complaining about is that when they stop the car (thereby stopping playback) and then start the car again, MM restarts the currently playing podcast. So Perhaps the simplest fix would be that 'stop' via Bluetooth or the Notifications panel should _always_ save the bookmark for bookmarkable content, _and_ that the bookmark should work in all cases (even if the user tries to resume playback from within the NP AA view). |
|
|
Fixed in build 1.1.3.486 |
|
|
Verified 486. |
