View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0005536 | MMW v4 | Now Playing | public | 2009-04-23 21:44 | 2016-12-23 19:29 |
| Reporter | rusty | Assigned To | |||
| Priority | urgent | Severity | minor | Reproducibility | always |
| Status | closed | Resolution | fixed | ||
| Product Version | 3.1 | ||||
| Target Version | 3.1 | Fixed in Version | 3.1 | ||
| Summary | 0005536: Now Playing scrolls by itself in cases where user wouldn't want it to | ||||
| Description | If 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. | ||||
| Tags | No tags attached. | ||||
| Fixed in build | 1249 | ||||
| related to | 0004003 | closed | Ludek | MMW v4 | Now Playing: If shuffle is enabled, and NP track is deleted, next track doesn't come into focus |
| related to | 0000023 | resolved | rusty | MMW v4 | Configurable Shuffle functionality (current behavior vs randomize list) |
| related to | 0013826 | closed | petr | MMW 5 | Now Playing node: list moves by itself |
|
|
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. |
|
|
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. |
|
|
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. |
|
|
Peke can you clarify what you mean?? |
|
|
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? |
|
|
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. |
|
|
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. |
|
|
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. |
|
|
Rusty, I'm also unable to replicate 6. could you please elaborate the issue? |
|
|
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) |
|
|
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? |
|
|
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. |
|
|
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. |
|
|
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 |
|
|
Fixed in build 1249. |
|
|
Verified 1250 |
