Window appears tiny if changing maximized state after idle

[Keith94]

mpv Information

mpv v0.41.0-dev-g35443a74c Copyright © 2000-2026 mpv/MPlayer/mplayer2 projects
 built on Mar  3 2026 02:19:01
libplacebo version: v7.361.0
FFmpeg version: 1834eb4
FFmpeg library versions:
   libavcodec      62.11.100
   libavdevice     62.1.100
   libavfilter     11.4.100
   libavformat     62.3.100
   libavutil       60.8.100
   libswresample   6.1.100
   libswscale      9.1.100

Other Information

- Windows version: 11 25H2
- GPU model, driver and version: 3070 ti mobile. driver 591.86
- Source of mpv: nightly.link master builds
- Latest known working version:
- Issue started after the following happened:

Reproduction Steps

1. Add this to mpv.conf

window-maximized

[idle-non-maximimzed]
profile-cond=idle and not p["current-tracks/video"]
profile-restore=copy-equal
window-maximized=no

2. Double-click on a file from file explorer to launch it in mpv.
   Note: The issue is not reproduced if launching from terminal, only file explorer.
3. Click on the restore button on title bar

Expected Behavior

Window size follows default behavior

Actual Behavior

Window is a very small 122x93 pixels

explorer_SmcQYeLdDS.mp4

Log File

output.txt. Note: The issue is not reproduced if launching from terminal, only file explorer.

Sample Files

No response

I carefully read all instruction and confirm that I did the following:

• I tested and confirmed that the issue exists with the latest release version or newer.
• I provided all required information including system and mpv version.
• I produced the log file with the exact same set of files, parameters, and conditions used in "Reproduction Steps", with the addition of --log-file=output.txt.
• I produced the log file while the behaviors described in "Actual Behavior" were actively observed.
• I attached the full, untruncated log file.
• I attached the backtrace in the case of a crash.

[kasper93]

Try #16127 build, I did extensive changes to related area. (might need to wait for new builds)

[Keith94]

@kasper93 I tried the build, but it's not fixed.. This particular issue appears worse too (it doesn't maximize nor unmaximize properly).

[kasper93]

Which version exactly did you test?

[Keith94]

Which version exactly did you test?

mpv-v0.41.0-dev-g0a3297348-pr16127-22824445612-x86_64-pc-windows-msvc

[kasper93]

I cannot reproduce, with old build (master) I see the same behavior as described. In the new build (pr16127) it seems to work fine for me.

[Sneakpeakcss]

I cannot reproduce, with old build (master) I see the same behavior as described. In the new build (pr16127) it seems to work fine for me.

I can still reproduce it (Win10).

There doesn't seem to be any difference between master and the 16127 build. I’m not seeing any new issues with min/max though.

However, on my side the initial window-maximized isn't set properly like in the example video.

On launch, the window starts in a bugged "maximized-windowed" state where it can't be drag-moved (similar to what happens when you set fullscreen while mpv is minimized and then restore it). The moment it's unmaximized, it ends up as a tiny window:

[   1.544][v][cplayer] Set property: window-maximized=no -> 1
[   1.545][d][osc] osc_init
[   1.545][d][cplayer] Run command: script-message-to, flags=64, args=[target="commands", args="input-event/0", args="edited", args="[\"\"]"]
[   1.545][v][cplayer] Set property: user-data/osc/margins={"l":0,"t":0,"r":0,"b":0} -> 1
[   1.546][d][vo/gpu-next] max content size: 1918x1018
[   1.546][d][vo/gpu-next] monitor size: 1920x1080
[   1.546][v][vo/gpu-next/win32] adjusted window bounds: -317:31:1186:758
[   1.547][v][vo/gpu-next/win32] Window size changed to: 208:208:136:100
[   1.548][v][vo/gpu-next] Window size: 120x61 (Borders: l=0 t=0 r=0 b=0)
[   1.548][v][vo/gpu-next] Video source: 1186x758 (1:1)
[   1.548][v][vo/gpu-next] Video display: (0, 0) 1186x758 -> (12, 0) 95x61
[   1.548][v][vo/gpu-next] Video scale: 0.080101/0.080475
[   1.548][v][vo/gpu-next] OSD borders: l=12 t=0 r=13 b=0
[   1.548][v][vo/gpu-next] Video borders: l=12 t=0 r=13 b=0
[   1.548][v][vo/gpu-next] Window size: 120x61 (Borders: l=0 t=0 r=0 b=0)
[   1.548][v][vo/gpu-next] Video source: 1186x758 (1:1)
[   1.548][v][vo/gpu-next] Video display: (0, 0) 1186x758 -> (12, 0) 95x61
[   1.548][v][vo/gpu-next] Video scale: 0.080101/0.080475
[   1.548][v][vo/gpu-next] OSD borders: l=12 t=0 r=13 b=0
[   1.548][v][vo/gpu-next] Video borders: l=12 t=0 r=13 b=0

mpv-v0.41.0-dev-gbbeee4ae8-pr16127-22846206412-x86_64-pc-windows-msvc.log

---

 

As a small side note… I can't say if it was intentional, but the mentioned above minimized->fullscreen->unminimized->fullscreen issue is fixed by #16127.
It was quite amusing being able to banish mpv into the shadow realm (pos -32000:-32000) just by cycling fullscreen.

[Keith94]

Thanks for testing.

window starts in a bugged "maximized-windowed" state where it can't be drag-moved
The moment it's unmaximized, it ends up as a tiny window

I can confirm that behavior in 16127 build.

Only in the master branch does the initial maximize work properly.

[kasper93]

It's probably a race in initial window configuration, but for me it doesn't happen. Could you try the new build from #16127. It should abort if we try to maximize in unexpected state.

[Sneakpeakcss]

It's probably a race in initial window configuration, but for me it doesn't happen. Could you try the new build from #16127. It should abort if we try to maximize in unexpected state.

mpv-v0.41.0-dev-g8608cd050-pr16127-22857342602-x86_64-pc-windows-msvc

Ekhm, so about that…

Happens only when opening a file, not when launching mpv.exe by itself, and only when using the mpv.conf from reproduction steps.

mpv still launches after ignoring it, but the bugged "maximized-windowed" state remains the same.