View Issue Details

IDProjectCategoryView StatusLast Update
0016029MMAPlaybackpublic2023-05-15 21:19
Reporterrusty Assigned To 
Status assignedResolutionopen 
Product Version1.3.5 
Target Version2.0.1 
Summary0016029: Tapping a track still replaces the entire queue (+ some prefer to tap-add individual tracks)
DescriptionIt seems that this option "'Play now' preserves the queue" doesn't work in some cases:
Play Playlist A. Tap track in playlist B --> Playlist B overwrites the NP list!

Note: the following case works as expected:
Play Playlist A. Select 3 tracks in playlist B and 'Play Now' --> The tracks are treated with 'Play next' as expected

Not sure if this is a regression in 1.3.5.

Do you want to create a new 1.3.5 build or include this in 1.3.6? I think it can wait.
Additional InformationReported at:
Additional feedback at:
TagsNo tags attached.
Fixed in build


related to 0011933 closedmartin It's easy to accidentally overwrite the current ad-hoc playlist 



2019-10-10 08:22

developer   ~0054998

Last edited: 2019-10-10 08:23

It's not regression, it was implemented for "Play now" action only.

How it should work when a user taps a track.

A) All collection tracks will be added to the end of now playing list. The tapped track starts to play.
N2 - original current track
C2 - starts to play (new current track)

B) All collection tracks will be added after the current track.
The tapped track starts to play.
N2 - original current track
C2 - starts to play (new current track)

I think for normal tap action A) is more clear, do you agree?


2019-10-10 12:54

administrator   ~0055001

Last edited: 2019-10-10 12:57

A) Is probably better.

btw, what do you think about an undo/redo function? I'd originally suggested that it was less preferable, but now I wonder whether it would be a cleaner approach since the current approach requires that the user enable this feature and many wouldn't want to because it 'breaks' the Play Now function.

Aside: another issue to consider is a way of preserving NP in different modes of operation. e.g.
1 User plays music
2 User switches to audiobook / podcast
3 User wants to resume music playback from stop 1--but currently there's no way to do this


2019-11-11 14:21

developer   ~0055305

I think this issue is not so urgent and need to be well tested, it's good be do it with testing new 2.0.0 so I would like to postpone it to 2.0.1.


2023-05-15 20:05

administrator   ~0071882

To review: there are 2 closely related requirements being raised by users:
1) Accidental erasure of the Playing list
2) Preference of some users to only add a single track to the playing list when tapping a track

MMA's initial approach tried, but didn't actually address the first issue, so I want to better explain the problem. The problem is that when the user is playing a queue and wants to add tracks to the queue, they must tap-hold tracks and then choose whether to Play now, Queue next, Queue last. There are 2 possible problems that can occur:
a) they accidentally tap a track instead of tap-holding a track. This causes the existing queue to be completely erased! This is the most common issue. The solution/mitigation strategies can be:
 i) Not to clear the list (as was originally proposed). This isn't a solution, but rather a kind of workaround until MMA supports Undo/Redo or Multiple queues.
 ii) Undo/Redo (probably a future feature)
 iii) Multiple queues (probably a future feature)
 iv) Optionally changing the default action for tapping a track to Queue next/Queue last. This isn't a solution, but rather a feature that would mitigate this issue for the subset of users that prefer the default behaviour to not play all tracks in a list).
b) they tap-hold a track and accidentally tap Play instead of Queue next/Queue last. This also erases the queue, but it is less likely to occur. The solution/mitigation strategies to this can be:
 ii) Undo/Redo
 iii) Multiple queues
Note: Not clearing the list (as is currently implemented) isn't a great solution as it results in a there being no obvious way to clear the Playing list!

With the above in mind, the preferred approach to solving issue 1) would be to implement undo/redo or multiple queues, but since that's likely non-trivial, then the next best thing would be to implement the current solution--but only when tapping tracks (and not when tapping a 'Play now' or 'Play shuffled' command).

At the same time, it might make sense to address issue 2) since it's part of the same thought process (what should happen when a track is tapped). This would result in the following:

Default action when tapping a track:
I Clear queue and play all
II Queue next and play all
III Queue next and play track
IV Queue last and play all
V Queue last and play track

One final point: the initial implementation could consist of just I and IV.