View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0016029 | MMA | Playback | public | 2019-10-10 02:14 | 2024-06-27 16:02 |
| Reporter | rusty | Assigned To | |||
| Priority | urgent | Severity | major | Reproducibility | always |
| Status | assigned | Resolution | open | ||
| Product Version | 1.3.5 | ||||
| Target Version | 2.0.2 | ||||
| Summary | 0016029: Tapping a track still replaces the entire queue (+ some prefer to tap-add individual tracks) | ||||
| Description | It 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 Information | Reported at: https://www.mediamonkey.com/forum/viewtopic.php?f=26&t=84034 Additional feedback at: https://www.mediamonkey.com/forum/viewtopic.php?t=103954 https://www.mediamonkey.com/forum/viewtopic.php?p=508144#p508144 | ||||
| Tags | No tags attached. | ||||
| Fixed in build | |||||
|
|
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. N1 N2 - original current track N3 N4 C1 C2 - starts to play (new current track) C3 B) All collection tracks will be added after the current track. The tapped track starts to play. N1 N2 - original current track C1 C2 - starts to play (new current track) C3 N3 N4 I think for normal tap action A) is more clear, do you agree? |
|
|
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 |
|
|
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. |
|
|
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. |
