View Issue Details

IDProjectCategoryView StatusLast Update
0000090madVRbugpublic2018-01-21 21:16
Reporter6233638 Assigned Tomadshi  
Status closedResolutionno change required 
Platformx64OSWindows 8OS Version6.2 (Build 9200)
Summary0000090: Display Mode Switcher changes to 23/59Hz rather than 24/60Hz with FSE Enabled on Windows 8
DescriptionThe display mode switcher is fixed in Windowed Mode, but still changes to the wrong refresh rates with Fullscreen Exclusive Mode enabled.
TagsNo tags attached.
madVR Version0.86.7
Media Player (with version info)JRiver Media Center 18.0.206
Splitter (with version info)LAV Splitter 0.58
Decoder (with version info)LAV Video 0.58
DecodingDXVA2 Copyback
Deinterlacingnone (progressive)
DXVA2 Scaling Activeno
Aero / Desktop CompositionOn
Problem occurs with modefullscreen exclusive mode
GPU ManufacturerNVidia
GPU ModelGTX 570
GPU Driver Version320.18 WHQL


has duplicate 0000157 closedmadshi Wrong displayrate for 24p source in fse 
has duplicate 0000140 closedmadshi Impossible to have a refresh rate at 24hz or 60hz when FSE mode is enabled 



2013-06-24 12:47

reporter   ~0000246

Only affects 'new exclusive fullscreen mode' (not the others: fullscreen windowed, overlay windowed, exclusive old path).

If I play a 23.97 fps content in 'new exclusive fullscreen mode' then the refresh rate of the screen is ~23.750 (so it not using 24Hz) and that why I get massive stutter. (Works correctly with all other fullscreen modes.)

OS: Win8, newest intel driver, nvidia v320.xx, lav, madvr, stable mpc-hc


2013-06-25 18:52

administrator   ~0000253

Which are your exact display mode changer settings?


2013-06-26 06:25

reporter   ~0000255

Switch to matching display mode when playback starts.
Restore original displaymode when media player leaves fullscreen.
Treat 25p movies as 24p

1080p24, 1080p50, 1080p60.


2013-06-26 08:20

administrator   ~0000256

Do you start movies directly in fullscreen mode, so madVR switches to FSE mode immediately at playback start, at the same time as switching display modes? Or do you start in windowed mode? In the latter case madVR should switch display modes while you're still in windowed mode, and then only later will switch to FSE mode. In the latter case: Is the display mode switched to correctly, while you're still in windowed mode, and the display gets wrong in the moment when you switch to exclusive mode?


2013-06-26 08:47

reporter   ~0000257

I start in windowed mode (switches correctly) and then to FSE mode (gets wrong).

I thought this was a known OS or driver bug and therefore unsolvable in madVR?


2013-06-26 08:54

administrator   ~0000258

Ok, I've double checked and I can actually reproduce it on my development PC. Don't know why I didn't notice it before.

I'm not sure if I can do anything about it, though, because the display mode is not changed by madVR when switching to FSE mode. It's changed by Direct3D. But I'll see what I can do...


2013-06-26 13:07

reporter   ~0000259

Thanks, but the strange thing is that it's working well with the 'fullscreen exclusive old path' .

My settings:
- start in window mode
- (I don't remember the exact names for the swithces, I'm sitting before a Mac :) )
Switch to matching display mode media player goes fullscreen.
Restore original displaymode when media player closes.

1080p24, 1080p25, 1080p30, 1080p60.


2013-06-26 15:59

administrator   ~0000260

Ok, I think I got it fixed, by hooking deep into Direct3D.

IMHO Windows 8 is really screwed up. There are 2 different situations/APIs now when the refresh rate I asked for gets ignored, and the OS afterwards reported that it did switch to the requested refresh rate, but actually it switched to a different refresh rate. Really bad.


2013-07-07 04:24

reporter   ~0000274

Last edited: 2013-07-07 04:27

24/60Hz are switching to 24/59Hz in 0.86.7 when in FSE mode, and switching to 23/59Hz in the test build.

Windowed mode works correctly.


2013-07-07 19:13

administrator   ~0000275

I can't reproduce that here with my HD4000. Which GPU/OS are you using? Please upload one debug log each for 24Hz and 60Hz, with the official v0.86.8 (just released).


2013-07-08 08:12

reporter   ~0000276

I have attached logs taken using 0.86.8
Nvidia GTX 570 using the latest WHQL drivers (320.49) on Windows 8


2013-07-08 08:31

administrator   ~0000277

Are you sure that's really v0.86.8? Unfortunately the log seems to skip the last version number, it only says "0.86". And are you sure you have the madVR display mode changer activated?

Your log is supposed to contain information about which refresh rate Direct3D tries to switch to, but this information is missing. That either means that you're not using v0.86.8, but an older version (MC18 sometimes likes to automatically replace it with an older version), or that you've not activated the display mode changer, or that for some reason my Direct3D refresh rate hook doesn't work at all in your case. But if it doesn't work at all, then I don't understand why you reported the refresh rate fix to partially work with v0.86.7. This is really confusing...

Can you also double check with MPC-HC, just to be safe?


2013-07-08 09:57

reporter   ~0000278

It's definitely v0.86.8, and the display mode changer is active. (I set my display to 50Hz so that it would have to change to 24/60)

New logs uploaded.


2013-07-08 10:03

administrator   ~0000279

Hmmmm... These logs are also missing the lines I'm looking for. It seems that the Direct3D refresh rate hook I've installed doesn't work for you. I don't know why, it works fine here. I guess I'll need to collect more feedback from other users. Maybe my fix only works for Intel GPUs? Although I wouldn't know why. I've no clue right now...


2013-07-08 10:25

reporter   ~0000280

Strange. I reinstalled 0.86.8 to be sure it was the right version, so I'm not sure why the logs are like that.

I only have Nvidia GPUs here that I can test unfortunately.


2013-07-08 13:26

administrator   ~0000281

Do you happen to have a dual monitor setup, maybe even using different GPUs? Here's a new test build, does it fix the issue?


2013-07-08 13:44

reporter   ~0000282

I only have a single display and GPU.
The test build doesn't change things, it's still switching to 23/59Hz in FSE.


2013-07-08 14:12

reporter   ~0000283

For me v0.86.7 and v0.86.8 behave the same. Both with display rate changer turned off or on and set to 1080p60 it will stay at 60p in FSE mode with the following exception:
If I play a PAL DVD first, which still stays at 60p, the next BluRay I play will switch to 59p. After restarting MPC-HC and playing a BluRay without playing a DVD first it switches back to 60p.
The internal MPC-HC display rate changer is off, of course.


2013-07-09 11:21

reporter   ~0000284

v0.86.7 doesn't working for me either. I'll try the test build this evening. Thanks.
To reproduce the problem easily:
- open a file with 25Hz content in FSE. After that go back to window mode
- open another file with 23.976 Hz without closing MPC-HC.
- it goes into 23.973 Hz (on my TV) not 24Hz.


2013-07-09 20:28

reporter   ~0000285

I have tried this one from yesterday: .
It's definitely better: when I start the player from closed state it's working.
But, as I described before:
- open a file with 23.796 fps content in FSE. After that go back to window mode
- open another file with 23.976 fps without closing MPC-HC.
- it goes into 23.972 Hz (on my TV) not 24Hz.


2013-07-15 22:18

reporter   ~0000287

Still switching to 23/59 in 0.86.9


2013-07-16 20:42

reporter   ~0000288

This might be a totally wrong suggestion as Windows probably creates its own HDTV resolutions and also because I have this issue as well, but you may want to try doing an EDID override with CRU. I currently do it to get 78Hz out of my screen for gaming (164.9MHz pixel clock so no patched drivers needed). Just make sure to uncheck include "Include extension block".

Now unfortunately, my monitor is actually an HDTV and as a result, HDTV resolutions get created. I'm looking into whether or not those resolutions also get created for regular 1080p monitors and if some data in the EDID block can be changed so as to force both higher pixel clocks(330MHz should be the max for HDMI) and the removal of these HDTV resolutions which are causing all of these problems. My gut feeling is no as the actual EDID in the monitor probably still gets read despite it being overridden.


2013-07-17 07:20

reporter   ~0000289

0.86.9 is switching to 23/59 Hz again, i.e. the fix introduced with 0.86.7 was removed completely.


2013-07-17 11:18

reporter   ~0000290

"i.e. the fix introduced with 0.86.7 was removed completely"
Which was not complete :)


2013-07-20 15:26

administrator   ~0000298

I'm not really sure what to say. The fix still works with my HD4000 GPU with v0.86.9. I've added slightly more logging once more. Those of you who still have problems with the next build (v0.86.10), please upload a v0.86.10 log.


2013-07-20 18:18

reporter   ~0000299

New log is attached.


2013-07-20 18:30

administrator   ~0000300

According to the log "nvd3dum.dll" is the DirectX driver used by your GPU, but for some reason the API I'm hooking to realize the FSE fix doesn't seem to be called on your PC. Maybe it depends on the GPU driver. I've only tested with Intel so far...


2013-07-22 11:00

reporter   ~0000310

I'm using Intel HD4000 + nvidia 650m . The nvidia is used for madrv (but since they are in muxless mode all the time, it doesn't really matter, at least I think.)

0.86.10 is working the same as the 0.86.8_test build:
- it switches correctly at 1st time
- and keep falling back to the bad behaivor after this (see my upper comment)

That means to me, that some checks are only done when the player starts (renderer is initialized at the first time), but not afterwords (when the renderer is already initialized).

How can I create a log?


2013-07-22 11:05

administrator   ~0000311

Double click "activate debug mode.bat" (or right click -> run as admin). After that madVR will write a debug log to your desktop. Try to reproduce the problem quickly to keep the log short. Afterwards zip it, it zips very well.

Try to have both the successful and the failing refresh mode switch in the log, that would be nice.


2013-07-28 14:57

reporter   ~0000323

Sorry for the late reply, I'll upload the log. It includes both the successful and the failing refresh mode switch.


2013-07-28 14:58

reporter (2,056,184 bytes)


2013-07-28 17:01

administrator   ~0000324


your log shows that the first time the Intel D3D driver is hooked by madVR, in the 2nd try the NVidia D3D driver is hooked. Seemingly in your case the refresh rate fix only works when the Intel D3D driver is hooked. I'm not sure exactly why it's sometimes the Intel driver and sometimes NVidia in your case. I'm asking the OS which D3D driver is reponsible for the display, in it seems that the OS sometimes reports Intel and sometimes NVidia. Not sure if there's anything I can do about it...


2013-07-29 10:59

reporter   ~0000326

Last edited: 2013-07-29 11:01

Thanks for the explanation. Well, it's strange, 'cause that means:
- at 1st ALWAYS inter is used
- and latter on (no matter how many times you load a new video into MPC-HC) ALWAYS the nVidia is used

As I mentioned before the 2 adapter in MUXLESS mode.

"According to the log "nvd3dum.dll" is the DirectX driver used by your GPU, but for some reason the API I'm hooking to realize the FSE fix doesn't seem to be called on your PC. Maybe it depends on the GPU driver. I've only tested with Intel so far..."
Is it apply to me in this case as well?

"Not sure if there's anything I can do about it..."
I'would be really sad, 'cause in this way I always have to quit manually from the player, so I can't use a remote to load another video into MPC :(
Thanks for your effort!


2013-09-08 19:08

reporter   ~0000340


same Problem here.
Win8 / GTX 670 / Madvr / MPCHC / Lav Filters

When i start a 24p movie the displayswitcher changes the Refreshrate to 23,976hz in FSE.
Without FSE (Windows Overlay) it changes correctly to 24Hz.
Any help?


2014-03-06 14:41

administrator   ~0000469

I think this should be fixed in v0.87.6.


2014-03-14 14:08

reporter   ~0000487

My problem is still exists with FSE (the old path is working fine though).


your log shows that the first time the Intel D3D driver is hooked by madVR, in the 2nd try the NVidia D3D driver is hooked. Seemingly in your case the refresh rate fix only works when the Intel D3D driver is hooked. I'm not sure exactly why it's sometimes the Intel driver and sometimes NVidia in your case. I'm asking the OS which D3D driver is reponsible for the display, in it seems that the OS sometimes reports Intel and sometimes NVidia. Not sure if there's anything I can do about it..."


2014-03-14 14:26

administrator   ~0000488

Argh, well, at least it seems for more people than it did before.

Can I have a new log with v0.87.7, please?


2014-03-14 16:09

reporter   ~0000489

Yes, I'll do it tomorrow. And thanks again!


2014-03-15 13:21

reporter (1,170,380 bytes)


2014-03-15 13:23

reporter   ~0000493

I have attached the new log file:
But the situation is worse than last time: it doesn't switch to the right (24.00 Hz) refresh rate anytime (not even the first time).


2014-03-15 14:15

administrator   ~0000494

The log this time only mentioned the Intel driver ("igdumdim32.dll"). The Intel driver seems to be responsible for the display you've been playing the video on. Can you confirm that's correct? Or is it the NVidia GPU? Which port is your DVI/HDMI cable plugged into? The NVidia GPU or the mainboard/Intel GPU?


2014-03-16 10:42

reporter   ~0000503

It's a MSI GE60 laptop, intel 4000 and GT650M, which are working in Muxless mode.
In nvidia settings (there isn't any display refresh rate settings) MPC-HC is forced to use nVidia, but the default is the intel for all other app.

The laptop has only 1 hdmi port, and MPC-HC and MadVR is using nVidia during playback (I use settings which couldn't be used by intel vga.)
But the old path is working fine, how come?

Win 8.1 (the previous log was created on Win 8), intel driver, nvida driver is 332.21 .


2014-03-16 11:57

administrator   ~0000505

I suppose this could have to do with the sharing of the GPUs somehow. I'm not sure which GPU actually drives your HDMI port. In a desktop PC when you have both Intel and NVidia GPUs, there are 2 physical ports. Not sure how this is handled in a laptop with only one port. I suppose probably one GPU is responsible for the port, and the other GPU then internally passes its rendering results forward to the port driving GPU.

The old path is using Direct3D9 instead of Direct3D9Ex. It seems that this makes all the difference. Seemingly Direct3D9Ex uses the wrong refresh rate and Direct3D9 does not. Unfortunately the new path absolutely requires Direct3D9Ex.


2014-03-16 13:16

administrator   ~0000506

Can you please try this build:

Older builds only enumerated the first GPU responsible for the current display. Enumeration stopped after the first GPU was found. Maybe for your PC more than one are listed? This new test build now enumerates and hooks all GPUs that are listed as responsible for your display.

Please upload the debug log for this build. Doesn't matter if the best build works or not, I'd like to see the debug log in any case. Thanks.


2014-03-17 10:47

reporter (2,681,930 bytes)


2014-03-17 10:49

reporter   ~0000513 is uploaded, thanks! (btw, it didn't worked :) )


2014-03-17 16:44

administrator   ~0000514

Oh well, I had hoped the OS would list all GPUs, but it only lists Intel. I'm not sure if hooking NVidia, too, would help or not. I guess I'm out of ideas atm... :(


2014-03-17 20:53



2014-03-17 20:58

reporter   ~0000515

Thanks, madshi! Just 1 more thing:
I have uploaded the well working old path log (of the current version), maybe you can see something regarding to the adapters. If you did, maybe a manual switch on the interface would do the trick.
(And an interesting thing: I have tried the old build of yours (, which was working always for the first time: now it doesn't do anything, that means something has changed on the OS level with Windows 8.1)


2014-04-02 16:32

administrator   ~0000564

I've now tested this with the following GPUs on Windows 8.1 x64:

- AMD HD7770
- nVidia 650
- Intel HD4000

Works for me with all 3 GPUs. Because of that I've now set this bug to "resolved". There isn't really anything else can do at this point. I'm not closing the bug yet, though, in case some new information comes up at some point.


2018-01-14 21:05

administrator   ~0002103

Last edited: 2018-01-14 21:06

FYI, I had reported this issue to Microsoft, and it seems in Windows 10 Fall Creators Update it's finally fixed!! Can you guys confirm?

Unfortunately there's no hope getting this fix backported to Windows 8.1, Microsoft told me... :-(

P.S: Make sure you have the option "hack Direct3D to make 24.000Hz and 60.000Hz work" in madVR disabled for Windows 10 Fall Creators Update.

Issue History

Date Modified Username Field Change
2013-06-20 18:20 6233638 New Issue
2013-06-24 12:47 chros Note Added: 0000246
2013-06-25 18:52 madshi Note Added: 0000253
2013-06-25 18:52 madshi Assigned To => madshi
2013-06-25 18:52 madshi Status new => feedback
2013-06-26 06:25 6233638 Note Added: 0000255
2013-06-26 06:25 6233638 Status feedback => assigned
2013-06-26 08:20 madshi Note Added: 0000256
2013-06-26 08:23 madshi Status assigned => feedback
2013-06-26 08:47 bugmenot Note Added: 0000257
2013-06-26 08:54 madshi Note Added: 0000258
2013-06-26 08:54 madshi Status feedback => assigned
2013-06-26 13:07 chros Note Added: 0000259
2013-06-26 15:59 madshi Note Added: 0000260
2013-06-26 16:00 madshi Status assigned => closed
2013-06-26 16:00 madshi Resolution open => fixed
2013-07-07 04:24 6233638 madVR Version 0.86.6 => 0.86.7
2013-07-07 04:24 6233638 Media Player (with version info) JRiver Media Center 18.0.201 => JRiver Media Center 18.0.206
2013-07-07 04:24 6233638 Splitter (with version info) LAV Splitter 0.57 => LAV Splitter 0.58
2013-07-07 04:24 6233638 Decoder (with version info) LAV Video 0.57 => LAV Video 0.58
2013-07-07 04:24 6233638 Note Added: 0000274
2013-07-07 04:24 6233638 Status closed => feedback
2013-07-07 04:24 6233638 Resolution fixed => reopened
2013-07-07 04:27 6233638 Note Edited: 0000274
2013-07-07 19:13 madshi Note Added: 0000275
2013-07-08 08:10 6233638 File Added:
2013-07-08 08:12 6233638 Note Added: 0000276
2013-07-08 08:12 6233638 Status feedback => assigned
2013-07-08 08:31 madshi Note Added: 0000277
2013-07-08 08:31 madshi Status assigned => feedback
2013-07-08 09:56 6233638 File Added: MPC-HC
2013-07-08 09:57 6233638 Note Added: 0000278
2013-07-08 09:57 6233638 Status feedback => assigned
2013-07-08 10:03 madshi Note Added: 0000279
2013-07-08 10:25 6233638 Note Added: 0000280
2013-07-08 13:26 madshi Note Added: 0000281
2013-07-08 13:26 madshi Status assigned => feedback
2013-07-08 13:44 6233638 Note Added: 0000282
2013-07-08 13:44 6233638 Status feedback => assigned
2013-07-08 14:12 bugmenot Note Added: 0000283
2013-07-09 11:21 chros Note Added: 0000284
2013-07-09 20:28 chros Note Added: 0000285
2013-07-15 22:18 6233638 Note Added: 0000287
2013-07-16 20:42 Mangix Note Added: 0000288
2013-07-17 07:20 bugmenot Note Added: 0000289
2013-07-17 11:18 chros Note Added: 0000290
2013-07-20 15:26 madshi Note Added: 0000298
2013-07-20 15:26 madshi Status assigned => feedback
2013-07-20 15:26 madshi File Deleted:
2013-07-20 15:26 madshi File Deleted: MPC-HC
2013-07-20 18:17 6233638 File Added: madVR -
2013-07-20 18:18 6233638 Note Added: 0000299
2013-07-20 18:18 6233638 Status feedback => assigned
2013-07-20 18:30 madshi Note Added: 0000300
2013-07-22 11:00 chros Note Added: 0000310
2013-07-22 11:04 madshi File Deleted: madVR -
2013-07-22 11:05 madshi Note Added: 0000311
2013-07-28 14:57 chros Note Added: 0000323
2013-07-28 14:58 chros File Added:
2013-07-28 17:01 madshi Note Added: 0000324
2013-07-29 10:59 chros Note Added: 0000326
2013-07-29 11:01 chros Note Edited: 0000326
2013-09-08 19:08 pajonk Note Added: 0000340
2014-02-27 11:50 madshi Relationship added has duplicate 0000157
2014-02-27 11:50 madshi Relationship added has duplicate 0000140
2014-03-06 14:41 madshi Note Added: 0000469
2014-03-06 14:42 madshi Status assigned => closed
2014-03-06 14:42 madshi Resolution reopened => fixed
2014-03-14 14:08 chros Note Added: 0000487
2014-03-14 14:08 chros Status closed => feedback
2014-03-14 14:08 chros Resolution fixed => reopened
2014-03-14 14:26 madshi Note Added: 0000488
2014-03-14 16:09 chros Note Added: 0000489
2014-03-15 13:21 chros File Added:
2014-03-15 13:23 chros Note Added: 0000493
2014-03-15 14:15 madshi Note Added: 0000494
2014-03-16 10:42 chros Note Added: 0000503
2014-03-16 11:57 madshi Note Added: 0000505
2014-03-16 13:16 madshi Note Added: 0000506
2014-03-17 10:47 chros File Added:
2014-03-17 10:49 chros Note Added: 0000513
2014-03-17 16:44 madshi Note Added: 0000514
2014-03-17 16:44 madshi Status feedback => acknowledged
2014-03-17 20:53 chros File Added:
2014-03-17 20:58 chros Note Added: 0000515
2014-04-02 16:30 madshi Status acknowledged => resolved
2014-04-02 16:30 madshi Resolution reopened => fixed
2014-04-02 16:32 madshi Note Added: 0000564
2018-01-14 21:05 madshi Note Added: 0002103
2018-01-14 21:05 madshi Status resolved => feedback
2018-01-14 21:05 madshi Resolution fixed => reopened
2018-01-14 21:06 madshi Note Edited: 0002103
2018-01-21 21:16 madshi Status feedback => closed
2018-01-21 21:16 madshi Resolution reopened => no change required