Chromium Window Zooming causes MM Progress Indicator Falls Short [#21157]

[MattTown]

Hi,

Was playing 3 hours of songs the other day and noted that the progress of the play indicator was no longer correctly aligned with actual progress of the song, through all of the session. The play progress indicator now goes only about 3/4 of the distance that it should, with the shortfall being progressive through the song; as in, it progresses at 3/4 rate all the way until the end of the song, stopping at 3/4 along the line when the song ends.

I routinely have my screen zoomed out (ctrl+mousewheel) to fit more columns into the central panel (this also affects the window minimise/mediumise/close control at top right of the MM window), but I haven't noticed the progress indicator not get to the end of the play progress line before version 3043.

Will submit a debugview log when next I see it happen.

Cheers
Matt

[rusty]

have my screen zoomed out (ctrl+mousewheel)

Wow--I learned something new today--thanks!
I'll try replicating this as well...

fyi: the Material design skins have a 'Small' option that'll help you fit more columns (without shrinking the player).

-Rusty

[Rob_S]

I was just trying this out myself, and I found that after zooming out quite bit (smaller text) the windows control butttons (minimize, close etc) no longer work.

[MattTown]

Rusty, how do I access that "small" control?

Rob,
I generated a prior post about the window control problem:

SCREEN ZOOM
... the window controls at top right (Switch to mini/microplayer, Minimise and Restore) don't work at anything other than the native zero zoom.

Update about the Progress Indicator:
Installed 3044 and the timeline progress indicator now gets to the end, like it should (even though that was not a noted fix), but I have noticed a different anomaly. To contextualise this, I need to explain that I use the progress indicator to terminate some songs at planned points, so knowing where the song is up to in time is important. I am used to placing the cursor onto the progress line to give me a time value and visual indicator of where to start muting the song.

The issue I'm reporting here is that the reported song duration at a point along the timeline depends on whether your cursor is slightly above the line, on the line, or slightly below; "slightly" in terms of only a couple of pixel heights.
Time values for half way along a 4:02 song are as follows:

• Above the progress line: 2:02

• On the progress line: 1:38

• Below the progress line: 2:02.

The upper and lower values agree (for the same location along the timeline), and appear to be the correct values for the relationship between place on the line and duration of the song. This behaviour is highly repeatable.
Now that I've quantified this behaviour it will be easy for me to fine tune timeline use to get what I want. But, you might like to look into it because the centre of the line gives the incorrect value, and when moving the cursor along the line it is easy to get a mix of correct and earlier times as the cursor strays off and on the centreline. Less-familiar users might see it as a point of unreliability.

Cheers

Matt

[rusty]

Rusty, how do I access that "small" control?

Options > Skin > Material design
In the 'Material Design configuration, you can then choose:
Theme: Orange, gray, green, etc.
Size: Small, Normal, Large

-Rusty

[rusty]

Matt,

fyi, another aspect of the bug is that changing the Zooming level, changes MMW's indication of time played. e.g.
1 Open MM and initiate playback
2 Pause after half the track has played and hover over the seekbar --> 1m35s
3 Zoom in and hover over the seekbar --> 2m23s
4 Zoom out and hover over the seekbar --> 1m11s

Rob,
Thanks--I can also replicate the issue of the windows controls not working

Tracking at https://www.ventismedia.com/mantis/view.php?id=21157

-Rusty

[MattTown]

I am glad to see that the issue of the progress indidator and window controls has been resognised, but sad to see that in the bug tracker the solution is:

"Disabled MouseWheel Zoom as window is correctly zoomed when DPI/resolution was changed."

So this issue is being managed by preventing access to the control that shows these two problems up, rather than fixing the problem in the code. I hope that this approach is just a bandaid for the sake of getting to the release candidate - which I could understand - and is not the final resolution.

I have followed Rusty's advice to adopt the Small option for the Material skin - thanks for that - but it doesn't quite go as far as I need. Is there a possiblity for a Very Small option?

Cheers
Matt

[Lowlander]

You can use a Skin like Material Design to set size or control size via DPI and/or Text Size settings in Windows.

[MattTown]

Thanks Lowlander, going to the Windows text size control and reducing the value there has got me the result I want.
Cheers