View Issue Details

IDProjectCategoryView StatusLast Update
0012893MMANow Playingpublic2015-10-15 22:04
Reporterrusty Assigned To 
PriorityurgentSeveritymajorReproducibilityalways
Status closedResolutionfixed 
Product Version1.1.3 
Target Version1.1.3Fixed in Version1.1.3 
Summary0012893: Bookmarking doesn't work correctly in Now Playing (regression)
DescriptionIf 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 InformationReported at: http://www.mediamonkey.com/forum/viewtopic.php?f=21&t=81509
TagsNo tags attached.
Fixed in build486

Activities

martin

2015-10-14 11:42

developer   ~0043111

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.

rusty

2015-10-14 13:39

administrator   ~0043114

Last edited: 2015-10-14 14:17

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).

martin

2015-10-15 10:54

developer   ~0043122

Fixed in build 1.1.3.486

rusty

2015-10-15 22:04

administrator   ~0043132

Verified 486.