View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0017679 | MMW 5 | Other | public | 2021-03-18 03:23 | 2021-10-11 14:45 |
Reporter | rusty | Assigned To | |||
Priority | urgent | Severity | minor | Reproducibility | always |
Status | closed | Resolution | reopened | ||
Product Version | 5.0 | ||||
Target Version | 5.0.3 | Fixed in Version | 5.0.1 | ||
Summary | 0017679: Status displays inconsistently / Hourglass appears but Status bar doesn't open for some background processes | ||||
Description | For most manually initiated activities, the status bar appears when the user clicks the 'hourglass'). But for some background-initiated activities only the hourglass appears (e.g. this was observed for volume analysis) while for others the status bar does appear. It's unclear what other cases this applies to. We should review the code if there are other such cases to ensure that clicking the hourglass always open the associated status bar. | ||||
Tags | No tags attached. | ||||
Fixed in build | 2409 | ||||
related to | 0017805 | resolved | Ludek | Podcast downloads run as a background process without status indication |
related to | 0015497 | closed | Ludek | Progress bar on bottom of main screen needs tweaking |
related to | 0017936 | new | Ludek | Download tree node: Download tree node only have always visible and Always hide |
related to | 0018312 | closed | Ludek | Import large Library from WMP and iTunes break MM scanning |
related to | 0018037 | closed | michal | Automated volume leveling: no status indicator displayed / crash (regression) |
related to | 0018240 | closed | drakinite | Background tasks circle icon cannot be used to terminate all tasks |
|
It seems that when MM downloads a podcast and then initiates volume leveling on the podcast, there's (sometime?) _no_ indication of this background process (i.e. neither hourglass nor in the status bar). This is bad because: - the user sees that MM is using CPU horsepower, but there's no indication of why - attempting to exit MM while this is happening results in a dialog indicating that background processes will be terminate, but the UI has no indication of what background processes are running Tracked at 0017805 |
|
Note, that clicking hourglass icon does nothing, status bar is always visible from 0015497 point 3) |
|
Fixed in build 2409. |
|
1. Clicking on hourglass do not show/hide Status/progress bar on Analyze volume is this behavior by design? 2. Disabling Downloading Tree node do not show hourglass and there is no way for user to know if download still happening (If trivial push to 5.0.2 as downloading progress status bar should be shown in this case). NOTE: Downloading tree Node is by default shown when there is download. |
|
1) as I wrote, it was decided to not hide statusbar at all in 0015497 point 3), it was confusing for people. 2) will be solved as 0017936 |
|
Verified 2409 Thx for clarification. Closing. |
|
The point that I'm trying to make is that the status bar implementation varies from one function to the next. In some cases such as ripping, the status bar is displayed at the bottom. In some cases such as background volume leveling, it displays only on hover at the top (and in such cases it's not possible to terminate the process). I just don't understand what the logic of this is (previously to 0015497 I could click on the hourglass to have the status bar show at the bottom, but now it sometimes shows as a status bar and sometimes as an hourglass, with no clear reason why)?? |
|
rusty: it was not intentional, it was bug, that background volume leveling did not show status bar. In case you have some other situation, where it does not work, please write here repro steps, thanks. |
|
In build 2414, Find moved/missing only displays as an hourglass (clicking the hourglass doesn't cause the status bar to display at the bottom). |
|
In build 2416, deleting tracks from the network while auto-analyze is ongoing, results in the status bar getting stuck on Deleting 809 of 809 (needs to be retested with logs). |
|
In 2417, both the hourglass and the status bar display when automated volume analysis is occurring. Need to test whether this occurs in other scenarios, but this approach (of displaying status indicators in duplicate) doesn't make sense. There needs to be a standard approach e.g. - background processes - use hourglass by default - foreground processes - use status bar by default Either should be switchable based on the user's preference (I'm pretty sure this is what was implemented originally). |
|
It was switchable between hourglass and hourglass+status bar, but as discussed in 0015497, users were confused and did not know, that clicking hourglass opens status bar, so it was removed, |
|
Every progress process is background process, not sure how you mean the differentiation, we do not differentiate such two cases. Every functionality could display in progress own progress task, no matter whether it was called by some user action or by scheduled task. E.g. analyzing volume progress is the same function with progress no matter whether it was called by user action or by scheduled task. |
|
1) Regarding what tasks are shown for the circle vs what is shown in the full task list: are you saying that they are now identical (I'm asking because this bug was originally raised because it seemed that the implementations were different--sometimes the circle would show without a corresponding task shown in the 'full' bar)? 2) I think that the problem in 0015497 was that the 'circle' indicator was the default indicator and users didn't understand how to re-enable the 'full' task indicator. So considering (and assuming that) the two indicators completely duplicate one another, and that the default is that 'full' task indicator is shown, would it make sense to re-enable the toggle? |
|
1) yes, they are identical. Circle is shown whenever there is at least 1 task, and each task has its progress bar. 2) Re-enabling the toggle would lead to confusion again. e.g. user would click the circle accidentaly > progress bar would be hidden and he couldn't know how to re-enable it. So resolving as "no change required" |