View Issue Details

IDProjectCategoryView StatusLast Update
0000327madVRbugpublic2015-10-09 16:30
Reporterromulous Assigned Tomadshi  
PrioritynormalSeverityminorReproducibilityalways
Status closedResolutionno change required 
Summary0000327: Zoom Player Playlist Window Forced to top in Fullscreen with FSE Enabled
DescriptionReported on the Zoom forums, and I can reproduce with the user's Zoom Player settings. The problem is not present in madVR v0.8.21 (the latest available via Install Center) but is present in the most current version (0.88.19) - I do not have any versions available between those to detect exactly when it was introduced however. The problem only occurs with FSE mode enabled in madVR, it does not occur with it disabled.
Steps To Reproduce1. Set Zoom Player to use madVR.
2. Ensure the FSE mode option is enabled in madVR.
3. Open the Zoom playlist and add a number of files to it.
4. Leave the Zoom Player playlist window open on screen - you can move it to the side of the Zoom Player window so you can see the video if you want.
5. Start the first file in the playlist playing in Zoom - and then go into fullscreen mode (remember, the playlist window has to be still open when you do this).
6. Wait until Zoom finishes playing the first file in the playlist and moves to the second file. At this point, the playlist window will appear on top of the Zoom Player window. It should not do this.
Additional InformationAs stated, this only occurs when FSE is enabled, and 0.87.21 is not affectedthe latest version available from Install Center) - the problem was introduced somewhere between 0.87.21 and 0.88.19
TagsNo tags attached.
madVR Version0.88.19
Media Player (with version info)Zoom Player 10.5 Beta 3
Splitter (with version info)LAV 0.65
Decoder (with version info)LAV 0.65
DecodingSoftware
Deinterlacingauto mode
DXVA2 Scaling Activeno
Aero / Desktop CompositionOn
Problem occurs with modefullscreen exclusive mode
GPU ManufacturerNVidia
GPU ModelGTX 660-Ti
GPU Driver Version353.30

Activities

romulous

2015-07-18 12:57

reporter   ~0001118

Found a download link for 0.88.16 and 0.88.17 - problem does not occur with .16 but does with .17, so that is where the problem starts.

romulous

2015-07-20 12:21

reporter   ~0001120

Still an issue in v0.88.20

romulous

2015-07-27 11:18

reporter   ~0001124

Still an issue in v0.88.21

romulous

2015-09-07 16:00

reporter   ~0001141

Still an issue in v0.89.0

romulous

2015-09-08 11:51

reporter   ~0001143

Still an issue in v0.89.1

madshi

2015-09-08 19:08

administrator   ~0001144

Done some tests. The issue was introduced by v0.88.17, which is not very surprising because that's the build which introduced a whole lot of rather deep changes.

The issue does not seem to be madVR's "fault". This seems to be just some unlucky timing problem. In previous madVR builds madVR didn't start rendering until it got the first frames from the decoder. But starting with v0.88.17, madVR now also renders in paused and stopped mode, and before the decoder start sending frames. This "early" rendering after switching from one file to the next in the playlist seems to be causing the playlist window to come to the top.

I'm not sure exactly *why* that happens. Must be some sort of timing issue with the "on top" state of the various windows involved, together with the weird stuff that happens when Direct3D enters FSE mode, and maybe in combination of whatever window manipulations ZP itself does at the same time.

The only way I could fix this would be to stop madVR from starting to render early, but I don't think that's a good idea. All those changes were done for a reason, so that all the media players can already use the madVR OSD functions even when playback is paused/stopped, or even no decoder is connected yet. And these new features are already put to good use by several media players out there.

So at this point I'm sad to say, this might be something Blight might have to look into. If I start trying to manipulate the Z order of specific media players from within madVR, all hell could break lose.

romulous

2015-09-09 17:09

reporter   ~0001148

Thanks. bLight has looked at this, and at the moment he thinks the solution is to add a function to Zoom to automatically close the playlist editor if it's supposed to appear on the same monitor as MadVR in FSE mode. I've added a bug report to this effect to Zoom's tracker so the issue can be tracked.

madshi

2015-09-09 17:28

administrator   ~0001149

Sounds reasonable to me.

Issue History

Date Modified Username Field Change
2015-07-18 12:44 romulous New Issue
2015-07-18 12:57 romulous Note Added: 0001118
2015-07-20 12:21 romulous Note Added: 0001120
2015-07-27 11:18 romulous Note Added: 0001124
2015-09-07 16:00 romulous Note Added: 0001141
2015-09-08 11:51 romulous Note Added: 0001143
2015-09-08 19:08 madshi Note Added: 0001144
2015-09-08 19:09 madshi Assigned To => madshi
2015-09-08 19:09 madshi Status new => feedback
2015-09-09 17:09 romulous Note Added: 0001148
2015-09-09 17:09 romulous Status feedback => assigned
2015-09-09 17:28 madshi Note Added: 0001149
2015-10-09 16:30 madshi Status assigned => closed
2015-10-09 16:30 madshi Resolution open => no change required