View Issue Details

IDProjectCategoryView StatusLast Update
0005536MMW v4Now Playingpublic2016-12-23 19:29
Reporterrusty Assigned To 
PriorityurgentSeverityminorReproducibilityalways
Status closedResolutionfixed 
Product Version3.1 
Target Version3.1Fixed in Version3.1 
Summary0005536: Now Playing scrolls by itself in cases where user wouldn't want it to
DescriptionIf focus rests on a track such that the currently playing track isn't visible, then when the next track starts playing, the view scrolls to the new currently playing track. This change of behavior was made on purpose so that if MM is in Shuffle mode, it's possible to see whatever track is playing (see 0004003 ).

This is annoying to users who are selecting/editing tracks in the Now Playing node/window and have the view scroll on them.

Possible fixes:
a) only switch to the currently playing track if no mouse activity has been detected in in the NP tracklist/window in x seconds
b) only switch to the currently playing track in the NP window (and not in the tracklist where users are more likely to perform edits)
c) ??

Long term a solid design for bug 0000023 would make this a non-issue.

Note: this can be pushed to 'urgent' if no quick/low risk fix is available.
TagsNo tags attached.
Fixed in build1249

Relationships

related to 0004003 closedLudek MMW v4 Now Playing: If shuffle is enabled, and NP track is deleted, next track doesn't come into focus 
related to 0000023 resolvedrusty MMW v4 Configurable Shuffle functionality (current behavior vs randomize list) 
related to 0013826 closedpetr MMW 5 Now Playing node: list moves by itself 

Activities

Ludek

2009-04-24 18:01

developer   ~0017580

Last edited: 2009-04-27 07:28

Assigning to me. I am about to implement a)

I have added 15 seconds timeout in which we don't want to scroll to the current track.

Fixed in build 1241.

peke

2009-05-08 17:32

developer   ~0017747

Last edited: 2009-05-08 17:36

a) Few sub issues cases:
I. Do not Scroll NP List to Playing track in case NP list is not in focus/selected and used edits and uses Track List to search for tracks in which case Timeout should be set either to lower value or disabled/handled with using Mouse Events.

II. In case track listing is set to now playing Timeout for track listing should be 15 sec and for Now Playing if visible it should Focus on Playing track.

Ludek

2009-05-10 20:34

developer   ~0017788

Rusty, I am not sure about the Peke's sub-issues and I don't fully understand them. Try to evaluate them, please. And then assign to me back.

Thx.

rusty

2009-05-11 21:42

administrator   ~0017797

Peke can you clarify what you mean??

peke

2009-05-12 17:51

developer   ~0017811

Last edited: 2009-05-12 17:52

Ok Here is Direct Example of three behaviors that should be different in case Now Playing List is Visible Like on My Screenshot (Uploaded to FTP).

Note that Now playing tree is Selected And MediaMonkey is playing.

Case 1:
1. Click on empty part of Tree which will make tree Focused list.
2. Press Next on keyboard
3. Both Track View will Scroll to Currently Playing track (15s Timeout is not even Considered)

Better Behavior in this case would be:
15 Sec Mouse Move Timeout on Track View
No Change in behavior for Now Playing

Case 2:
1. Click to select track in Track View
2. Press Next on keyboard
3. Both Track View will not Scroll to Currently Playing track (15s Timeout is in action), but if you wait 15 sec and press next both will Scroll to Current track so this could be considered as desired/designed.

Better Behavior in this case would be:
15 Sec Mouse Move Timeout on Track View
Focus on Currently Playing track for Now Playing (Override Timeout) due the fact that current Selection/Position is preserved within Track View

Case 3:
1. Click to select track in Now Playing
2. Press Next on keyboard
3. Both Track View will not Scroll to Currently Playing track (15s Timeout is in action), but if you wait 15 sec and press next both will Scroll to Current track so this could be considered as desired/designed.

Desired Behavior in this case would be:
15 Sec Mouse Move Timeout on Nowplaying
Focus on Currently Playing track for Track View (Override Timeout) due the fact that current Selection/Position is preserved within NowPlaying

Case 4 (Regression ?):
1. Browse MM Tree
2. Press Next on keyboard
3. Now Playing will Scroll to Currently Playing track (15s Timeout is not even Considered but it should be)

NOTE Case 4 can be easily reproduced if you click on any other MM object Except Track View/Nowplaying (Toolbars or open Menu)

Ludek, my guess is that this is standard issue how Delphi handle Mouse Move event, but rather I would Suggest that Enter/Out events are also Considered but rather on Main Window than only on Track View/Nowplaying and internal focus Function would decide behavior as explained in cases 1-3?

Ludek

2009-05-12 22:50

developer   ~0017823

You seem to be right in cases 2) & 3). The two Now Playing windows should be independent so that only the one (on which the mouse activity has been) wouldn't scroll.
-> Cases 2) & 3) fixed in build 1245.

I am not sure about cases 1) and 4). I think that MM should not scroll to the currently playing track only if the mouse activity has been detected in the focused NP window as Rusty proposed.
I see no regression.
Btw. I shortened the interval from 15 seconds to 10 seconds. It should be the appropriate time in which user usually stops browsing the NP window.

rusty

2009-05-13 20:14

administrator   ~0017832

Tested 1245 and it's working quiet well, though I noticed a couple of issues:

5) If a track is focused in the NP Window, then the NP Window _never_ automatically adjusts to the currently playing track (after 10 seconds) in response to CTRL-N.
In contrast, if a track is focused in the NP Node, then the tracklist _does_ automatically adjust to the currently playing track (after 10 seconds) in response to CTRL-N.

I think that the preferred behavior is that of the NP Window.

6) If Shuffle isn't enabled, this functionality doesn't seem to work. i.e. The window moves despite the fact that the cursor is focused on a particular track and is active.

Ludek

2009-05-14 13:34

developer   ~0017846

5) fixed in build 1246.

6) I have not been able to reproduce this, but I made some changes that probably fixed the case.

Fixed in build 1246.

peke

2009-05-15 00:16

developer   ~0017856

Rusty,
I'm also unable to replicate 6. could you please elaborate the issue?

rusty

2009-05-15 09:26

administrator   ~0017860

Verified 5) in 1246.

I can still reproduce 6) as follows:
-Disable shuffle
-Double click a track in the NP Window (or node)
-Immediately click CTRL-N (several times if necessary, depending on the position of the NP track)
-->The NP window or trcaklist will scroll (once the position of the NP track is beyond the halfway point of the NP window)

Ludek

2009-05-15 11:00

developer   ~0017880

Last edited: 2009-05-15 11:34

Rusty, I haven't been able to reproduce, see this short video:
http://www.yousendit.com/download/MnFqTkFxZy8wVWxMWEE9PQ
to see that I simply cannot reproduce it.

What do I wrong?

rusty

2009-05-15 12:32

administrator   ~0017882

I see... when Tools > Options > Auto-DJ/Now Playing > Automatically retain _x_ tracks in Now Playing is set to 'All', the bug doesn't occur. But if it is set to e.g. '10', the bug occurs.

Ludek

2009-05-15 12:39

developer   ~0017883

Last edited: 2009-05-15 12:40

Ok, but this is not a bug, because if that option is ON then it means that the tracks are auto-deleted from NP list and therefore the window scrolls. So I guess there is nothing to fix. Thank you for clarification.

rusty

2009-05-22 01:34

administrator   ~0017960

Issue 7) If the user manually triggers a change in track, then MM should scroll to the newly playing track, regardless of the timer. Currently, if the user e.g. clicks Next/Previous, focus doesn't shift to the new track unless the timer has expired.

Rationale reported at: http://www.mediamonkey.com/forum/viewtopic.php?f=6&t=38865&st=0&sk=t&sd=a&start=30#p204520

Ludek

2009-05-23 20:59

developer   ~0017998

Fixed in build 1249.

peke

2009-06-05 12:29

developer   ~0018177

Verified 1250