View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0016622 | MMW 5 | Now Playing | public | 2020-05-15 18:19 | 2024-03-25 12:11 |
| Reporter | rusty | Assigned To | |||
| Priority | urgent | Severity | minor | Reproducibility | always |
| Status | closed | Resolution | fixed | ||
| Product Version | 5.0 | ||||
| Target Version | 5.1 | Fixed in Version | 5.1 | ||
| Summary | 0016622: Now Playing: Unexpected behavior when Changing Sort order | ||||
| Description | In MM5, changes to playlist sorts are relatively intuitive: Change in sort order cause a 'Save' button to appear, and the original play order can be seen via the '#' column. Pressing F5 reverts to the actual playlist order, and pressing 'Save' re-saves the playlist with the new play order. For auto-playlists, a similar approach is taken, the only difference being the absence of a 'Save' button (since it would be unclear what is being saved in the context of an auto-playlist). For the Playing list, there's a different implementation. Changes in sort order effect an immediate change to the Play order, and the user must 'Undo' the change to revert it. There are a couple of issues with the current implementation: 1) On changing the sort order, the currently playing track is no longer highlighted (regression from 4.x) 2) The next track that plays is not the one after the currently playing track, but rather the track in the +1 position following the original position of the playing track. e.g. if MM was playing 50. A Flock of Seagulls - Space Age Love Song, and the user sorted by Artist, causing that track to appear as track #2, then the next track to play would be 51. xxx - yyy . This issue only occurs for the first track played after the sort order change (regression from 4.x) 3) It's inconsistent with how Playlists work 4) There's no way to sort the NP list (e.g. to see which artists have multiple tracks) without committing the changes. 5) It's unclear whether or not the play order has changed (it has) 6) It's unclear how to revert the change (user must go to the NP column, click the overflow menu, and then 'undo') The solution to 3/4/5/6 would be to take the same approach as is used for Playlists. i.e. don't commit the sort order change unless the user clicks a 'save' button that appears. Note: this would mean that the 'Playing' list in the right hand column would always be sorted by play order (unlike the Playing tracklist which could display according to a sort order). I expect that this is risky for 5.0 implementation. | ||||
| Tags | No tags attached. | ||||
| Fixed in build | 2818 | ||||
| related to | 0018438 | closed | michal | Podcast Export Subscribed export button rendered too large in toolbar / buttons perform wrong actions |
| parent of | 0020249 | closed | michal | Playing Node loses files |
| has duplicate | 0019443 | closed | petr | Now Playing Changed play Order can't be saved |
| related to | 0017102 | closed | Ludek | Playlists: Sort became permanent on Playlist change |
| related to | 0018096 | closed | michal | Playing: # column isn't displayed in the List view |
| related to | 0018496 | feedback | rusty | Manual reloading/refreshing of Auto-Playlists |
| related to | 0018776 | closed | Ludek | Automatically retain X files in Playing list does not work when Shuffle is enabled |
| related to | 0016061 | feedback | rusty | Playing list (panel): Numerous issues with Randomize List functionality |
| related to | 0018988 | resolved | michal | Make Shuffle mode display track order (and related improvements) |
| related to | 0020124 | assigned | michal | Inline search of Playing is auto applied to Now Playing |
| related to | 0020120 | closed | michal | Can't save Playlist order after column sort [Regression] |
| related to | 0020272 | closed | michal | Menu items from one tab appear on other tabs |
| related to | 0020279 | closed | Ludek | Web node doesn't work [regression 2817] |
|
|
1) and 2) fixed in build 2275. |
|
|
I still think that this can be improved, but pushing to review for 5.1 since the current implementation is the same as 4.x. Other things to consider: - retention of play order of previously played tracks - how this fits with shuffle (which changes play order in a hidden fashion) / randomize (which changes play order in a visible fashion) |
|
|
The fundamental issue here is that most users would not expect that sorting the list would modify the play order. So my preference is to implement the 'Save new order' functionality currently used with Playlists. Regardless of whether or not we implement the above, in the short term we should at least add the 'Playing' commands (the ones that appear in the Playing Element) to the Playing [List] view. That way users can at least undo play order errors caused by sorting. But to re-iterate--this problem should also be prevented from occurring in the first place. |
|
|
Playing Menu button added to NP view - List in build 2509. Resolving so you can test it. I still think, sorting with special save button is problematic and not systemic, reasons described above. |
|
|
Verified button functionality in 2509. |
|
|
Re verified 2510 buttons works OK Reopened for Feedback about further functionality/triage. |
|
|
I think that the remaining issues should be tackled at the beginning of the 5.0.3 cycle. |
|
|
With the new 'Shuffle' functionality, this issue has gotten more exposure; If 'Shuffle' mode is enabled and the user sorts the Playing view, it immediately updates the Play order and the shuffle is lost! While it's true that the intent of the revised functionality in 5.1 is for the user to be able to see tracks in the Playing list in the order in which they're played, this makes sense for 'Shuffle', but it's unexpected for most users that sorting tracks in this view would trigger a change in the Play order and lose the shuffle. The workaround implemented so far it to include the Playing menu in the Tracklist > Playing view so that the user can easily Undo such changes, but I think I agree with Peke that it would be preferable that the default behavior when sorting this view would not be to also modify the Play order. Would either of Ludek's idea of using a toast be feasible? e.g. a ?10s toast: 'Update play order to match sort order? [Yes] [[No]]'. - in most cases the user will leave the default of 'No', and the display order will change but the play order will be unchanged--i.e. the numbers in the '#' column will show out of order and the user can click the # column to revert the sort back to the Play order. - if the user click 'Yes' the # column/play order will change to match the sort order Note: if we take this approach, we'd probably want MM to always sort by Play order in a Playing view that doesn't contain the '#' column (since display order can't be reverted to Play order if the '#' column is missing) OR if the field by which the user sorted the list isn't displayed (since the user wouldn't know why the tracks are out of order). |
|
|
Skype discussion between Michal & Rusty on this: "But if we resort the Playing view without affecting real playing order, what this view in fact would show?" -It would allow the user to browse the list by other attributes e.g. if they want to see what years the tracks in the list are from. The benefits are the same as in the Playlist view. "And what if user changes order by drag&drop of some files before or after sorting, should it change playing order or not, should it always display the toast to apply changes also to playing order?" - It would work the same way as in Playlists view. i.e. when the list has been sorted (unsaved in the Playlist node) d&d is disabled. "Currently playing view and playling list is exactly the same instance of the list. Implementing the approach with different order will need to handle two lists and synchronize everything except order between them." - Does anything need to be synchronized? The actual list is the same in both bases--the only difference is the display order. e.g. the tracklist version of the Playing list could allow change in display order based on column headers, whereas the small version that appears in the panel would always use the play order as the display order. |
|
|
Fixed in build 2815. Used similar approach as for playlists with Save button, F5 resets order. @rusty re synchronizing - we can sort one list only in one way, we do not support several orders of the same list instance, order is integral part of each list. It would be extremely difficult to make it differently, in fact rework everything related to all lists in the app. So now NP view uses copy of original list and lists are synchronized. |
|
|
Reopening, it does not work correctly, when order column is hidden. |
|
|
Fixed in build 2817. |
|
|
Verified 2817 |
|
|
This functionality isn't working correctly in 2817, since re-ordering tracks in the Playing panel causes playing list view to become corrupted in a number of different ways: a) when shuffle is enabled, re-ordering changes in the panel combined with sort order changes cause duplicates to appear in the list view, and existing tracks in the view to become hidden b) Once the above bug occurs, then re-ordering changes in the panel aren't reflected in the list view even when Shuffle is disabled This can be replicated as follows (the steps are not exact, though as the bug doesn't occur consistently, but it always occurs after doing these steps several times)): 1 Initiate playback of track 5 in Playlist Y 2 Navigate to the Playing node so that the Playing list displays 3 Sort the Playing list by Artist 4 In the Playing _panel_ move track 10 to the position 6 5 Sort the Playing list by # --> The Playing list doesn't reflect the change from step 4 (issue a)!! 6 Sort the Playing list by Artist 7 Wait for track 6 to play 8 Sort by # --> Some tracks appear in duplicate and some of the duplicate tracks overwrite existing tracks in the Playing list (issue b)!! |
|
|
Fixed in build 2818. |
|
|
Verified 3007 I think that this works OK for now |
