View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0007494 | MMW v4 | DB/FileMonitor | public | 2011-03-09 18:45 | 2013-01-10 13:47 |
| Reporter | rusty | Assigned To | |||
| Priority | urgent | Severity | major | Reproducibility | always |
| Status | assigned | Resolution | reopened | ||
| Product Version | 4.0 | ||||
| Target Version | 4.1.1 | Fixed in Version | 4.0 | ||
| Summary | 0007494: Scanning interferes with usage of the tracklist (regression) | ||||
| Description | When scanning files into the library, the tracklist / filelist moves by itself, making the tracklist unusable. | ||||
| Tags | No tags attached. | ||||
| Fixed in build | 1426 | ||||
|
|
I've tried in MM3 and it work exactly same (tracklist will always scroll to focused node). |
|
|
The behavior that I observed was that MM was flipping to the beginning of the tracklist, but I can't figure out how to reproduce that. Closing. |
|
|
Figured it out. It occurs when scanning if the user switches to AA View without the Column browser active. Edit: I've also observed this to occur on occasion on Track change in the Now Playing list (i.e. New track starts playing --> position of the tracklist changes), but I cannot determine repro steps. |
|
|
Unable to reproduce in 1358. Retest in 1359, please. |
|
|
Verified No reproduce with 1367 |
|
|
This issue is reproducible in 1419 and makes MM unusable during the scanning process due to: 1) The tracklist continually scrolls back to whatever track is selected (even when the user has manually scrolled to a different location) 2) If the user tries to edit a track (via F2) the edit box loses focus each time a track is scanned |
|
|
Fixed in 1423 |
|
|
Tested 1423 and the bug still occurs in Art, Art & Details, and Details views. Reproduce as follows: 1 Scan a drive 2 Select the first track 3 Scroll down the tracklist --> MM will scroll back up to the selected track by itself |
|
|
Fixed in 1424 |
|
|
This still occurs in build 1425. |
|
|
There was a regression in Art Browser and when Track Browser is enabled. Fixed in 1426. |
|
|
It's much better in both the Art View and A&D view, though it still jumps around periodically. I hope that can improve a bit further if possible. The Details view is quite bad though. It continually jumps. |
|
|
It's jumping because new tracks are adding to the list (so it's always stay at the same position from the top of the list). |
|
|
To clarify, the suggestion being raised is that when you have tracks A C D and only C and D are within the visible portion of the tracklist, then if track B is scanned, it would need to fit between A and C. So with the suggested approach, there would no longer be updates to the display when Album B is added (since C is the first visible item). (Unlike the current situation in which any time a track is added above the current visible location, the tracklist moves). Another example would be with Album Art e.g. for albums: A B C D E F G H I J K L Currently, if albums DEF,GHI are on the screen and album K1 is added, nothing happens. BUT if album B2 is added, then every entry on the screen is redrawn so that it appears as: C D E F G H I would suggest that the behavior with K2 is correct, but that the behavior with B2 is not. i.e. the tracks on the screen shouldn't change because: - There are no new albums within the currently displayed range - The user hasn't moved (or triggered a move of) the scrollbar Note also: on a fresh install, build 1426 _does_ repeatedly jump to the currently selected track (for the details view). |
|
|
There are some performance issues with this implementation i need to solve, but it need some more updates so i prefer to postpone to 4.1 (because of regression risk). |
