[Windows] When starting mpv with --pause and --start, taskbar progress isn't shown. #3482

Closed
pavelxdd opened this Issue Sep 2, 2016 · 5 comments

Projects

None yet

2 participants

@pavelxdd
Contributor
pavelxdd commented Sep 2, 2016

mpv version and platform

mpv --version
mpv git-453fea8 (C) 2000-2016 mpv/MPlayer/mplayer2 projects
built on Fri Sep 2 02:10:04 MSK 2016
ffmpeg library versions:
libavutil 55.28.100
libavcodec 57.48.101
libavformat 57.41.100
libswscale 4.1.100
libavfilter 6.47.100
libswresample 2.1.100
ffmpeg version: 3.1.3

Reproduction steps

Start the mpv with --pause and --start,
for example mpv *.mkv --start=5:00 --pause

Expected behavior

Taskbar progress should be visible and have a color of paused state.

Actual behavior

Taskbar progress will only be rendered after starting the playback.

Log files

http://sprunge.us/MeWS

@wm4 wm4 added a commit that closed this issue Sep 2, 2016
@wm4 wm4 player: don't send win32 taskbar update before window is created
If the win32 taskbar progress update is sent before the VO window is
created, then w32_common.c will ignore it because the actual taskbar
object was not created yet. (At least this is what I suspect happens.
The window is already created at this point, but not mapped.)

Hopefully fix this is fixed by creating until after the window is
created, i.e. the VO has been configured at least once.

Untested (who wants to boot into Windows just to wait until it has
applied all of its stupid updates).

Also not explicit is whether update_vo_playback_state() will actually be
called soon enough in all cases. It probably is.

Probably fixes #3482.
f2e25e9
@wm4 wm4 closed this in f2e25e9 Sep 2, 2016
@wm4
Member
wm4 commented Sep 2, 2016

This likely fixes it, but I didn't test it myself.

@pavelxdd
Contributor
pavelxdd commented Sep 2, 2016

I launched the video a few times, and taskbar was rendered correctly only on ~2 times out of 10.
Seems like it's not fixed.

@wm4
Member
wm4 commented Sep 2, 2016

Could reproduce on a real windows, fixed locally.

@wm4 wm4 added a commit that referenced this issue Sep 2, 2016
@wm4 wm4 w32_common: initialize playback status as soon as possible
On a VOCTRL_UPDATE_PLAYBACK_STATE store the state, and use it to
initialize the next time the task list becomes available.

This actually fixes #3482. Revert commit f2e25e9 because it's not
needed anymore.
c4faf34
@wm4 wm4 added a commit that referenced this issue Sep 2, 2016
@wm4 wm4 w32_common: initialize playback status as soon as possible
On a VOCTRL_UPDATE_PLAYBACK_STATE store the state, and use it to
initialize the next time the task list becomes available.

This actually fixes #3482. Revert commit f2e25e9 because it's not
needed anymore.
d216a50
@wm4 wm4 added a commit that referenced this issue Sep 2, 2016
@wm4 wm4 w32_common: initialize playback status as soon as possible
On a VOCTRL_UPDATE_PLAYBACK_STATE store the state, and use it to
initialize the next time the task list becomes available.

This actually fixes #3482. Revert commit f2e25e9 because it's not
needed anymore.
b92d3b6
@wm4
Member
wm4 commented Sep 2, 2016

Pushed the fix a while ago.

@pavelxdd
Contributor
pavelxdd commented Sep 2, 2016

Yes, it's fixed now. Thank you!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment