View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0017725 | MMW 5 | Podcasts | public | 2021-04-05 17:54 | 2021-05-13 01:30 |
| Reporter | Ludek | Assigned To | |||
| Priority | urgent | Severity | minor | Reproducibility | always |
| Status | closed | Resolution | fixed | ||
| Product Version | 5.0 | ||||
| Target Version | 5.0.1 | Fixed in Version | 5.0.1 | ||
| Summary | 0017725: Refreshing number in Downloads(X) collapses manually opened album | ||||
| Description | As reported by user from ticket # 1085: Steps to reproduce: 1) Open Mediamonkey 2) Downloading of quite large number of podcast starts (30 pieces to have time to elaborate the issue) 3) Search and open any Album (example of the view is here https://www.mediafire.com/view/qmieod1dz9q1mbe/example_for_correct_terminology_collapse_vs_open_album.png/file) So, I pressed "Show all Y tracks" 4) When the number in the Downloads node refreshes (increases or decreases), the open Album is collapsed, such as I would do that manually by pressing Collapse -- but I did not. Expected behaviour instead of 4: Album is not collapsed on any background activity of MM and Album remains open. MM5 build 2330 RC-6 | ||||
| Tags | No tags attached. | ||||
| Fixed in build | 2403 | ||||
|
|
Partially fixed in 2232 But the problem is actually more general, currently editing any track property triggers the bug. e.g. changing rating of a track in Playing list on the right causes the expanded albums in "List (by Album)" view on the left to auto-collapse. Debugging it further and the reason is that after any property change the 'autoupdate' event is called resulting in calling ListView.handleItemChange with eventType == 'autoupdate' and thus GroupedTracklist.invalidateAll() is called that re-creates the groups and auto-collapses the albums. Assigned to Petr to check whether there is an easy and low risk fix for 5.0 -- otherwise pushing to 5.0.1 |
|
|
Fixed |
|
|
Verified 2404 Unable to reproduce. |
