View Issue Details

IDProjectCategoryView StatusLast Update
0017641MediaMonkey 5Now Playingpublic2021-10-21 09:40
Reporterrusty Assigned To 
PriorityhighSeverityminorReproducibilityalways
Status newResolutionopen 
Product Version5.0 
Target Version5.0.3 
Summary0017641: Initiating playback doesn't trigger playing to scroll to the playing track
DescriptionIf the user isn't selecting/editing within the Playing list, then clicking PREVIOUS/NEXT causes it to auto-scroll to the playing track. This doesn't work correctly if the user presses PLAY to initiate playback that has been stopped if the playing list isn't positioned at the currently playing track. e.g.
1 Run MM, double-click a track
--> Playing list auto-scrolls to the position of the playing track and continues to do so as each new track starts playing (if the user isn't actively selecting/editing a track in NP)
2 Stop playback
3 Scroll through the Playing list
4 Click the PLAY button
--> The correct track starts playing, but the Playing list doesn't auto-scroll to it in the Playing list!

Clarification: the suggested change is that STOP-->PLAY should initiate auto-scroll (Pause-->Play shouldn't, as is currently the case).

Note: this isn't critical since the issue corrects itself i.e. as soon as the next track starts playing, the Playing list auto-scrolls to the correct position
TagsNo tags attached.
Fixed in build

Relationships

related to 0017615 closedmichal Playing not focused on active file on MediaMonkey start (regression 2316) 

Activities

rusty

2021-03-09 19:12

administrator   ~0062316

Last edited: 2021-03-18 13:58

View 2 revisions

In addition, when switching to a different NP view, the list doesn't show the playing track. e.g.

1 Switch from Music > Artists to Playing > List
--> the List view displays from the top (instead of centered around the currently playing track)!

2 For the Playing element, switch from Simplified list to List (or vice versa)
--> the list displays from the top (instead of centered around the currently playing track)!

Michal indicated that this could conflict with current Listview restoration logic. This is a really minor case since it only occurs on config changes so it can probably be deferred indefinitely.