Call for tester for 1.4.0 features and fixes (4 Viewers)

[Scythe42]

Will do a full RegisterDeviceNotification() handling so I can get information what actually gets disconnected/connected. In case of a sound device I just stop playback. That should solve problems with the audio device. In other words: when you turn off your receiver MP will stop playback.

Yes, would be better if it is exactly the device as currently used in playback. But unlinkely a lot of users have constant audio device connection/disconnections. Fine tuning can be done at a later point. It's just about bringing stability to all of this for now.

Susped/Resume will be worked on separately anyway as this might involve the D3D device reset that never worked properly anyway as long as I used MP.

 

[tourettes]

Will do a full RegisterDeviceNotification() handling so I can get information what actually gets disconnected/connected. In case of a sound device I just stop playback. That should solve problems with the audio device. In other words: when you turn off your receiver MP will stop playback.

With MPAR we can probably render and then recover the device in the future - for example stopping a live tv because some one switches tv input and that causes the timeshifting buffer to lost is not the thing we want to have.

But it is for the future.

Susped/Resume will be worked on separately anyway as this might involve the D3D device reset that never worked properly anyway as long as I used MP.

DirectX 9Ex guarantees the device not to reset on S3/S4 cycles. If it happens then it is a driver bug. When the DirectX 9Ex was implemented it was even tested that a video playback (both video + audio) continue without any extra tricks on MP side with S3/S4 cases.

Also Windows XP + refresh rate changer is relying on the device reset, as far as I remember.

 

[Scythe42]

Sure, we can add any kind of messages to notify other parts of changes or even override stuff. That should be relatively easy by just checking device class and/or device name.

The DirectX9Ex device - at least on my system - comes back with a GPU_HUNG after several suspend/resume cycles and can't even be re-created with the current code. But that's a bug we create on our own in the code that is still based on the d3dapp.cs sample from MS.

When working on the resume/suspend part I'll find out where this strange behaviour comes from. As said never worked for me - might be a GPU driver bug though. Will find out. But at least it should be trapped, even if it is not supposed to happen.

Resuming/Standby and playback (including pausing) has some other issues as well, when the file is on a network path that isn't available anymore. MP hangs here as it still assumes the file is open but in fact windows has closed it. Also an issue I had for years. The DS graph itself doesn't have this problem it is something MP is doing as GraphEdit works fine...

And XP -> yeah, probably broken at the moment. Once everything is finished and I find an XP tester we'll add the necessary code back in with a XP only execution path. Right now there are two many check of EVR/VMR/Exclusive Mode/FullScreen/Windowed whatever that all interfere with one another.

 

[Scythe42]

Let's see where we are. Quick test in a VM. Therefore so no HDMI audio connection with a display or a receiver. So it might be a bit stranger then on a normal system.

2013-01-10 01:30:48.705078 [Info.][MediaPortal(1)]: Main: DBT_DEVICEREMOVECOMPLETE
2013-01-10 01:30:48.705078 [Info.][MediaPortal(1)]: Main: Device Name: Generic Non-PnP Monitor
 
2013-01-10 01:30:48.736328 [Info.][MediaPortal(1)]: Main: DBT_DEVICEREMOVECOMPLETE
2013-01-10 01:30:48.736328 [Info.][MediaPortal(1)]: Main: Device Name: Generic Non-PnP Monitor
 
2013-01-10 01:30:48.992187 [Info.][MediaPortal(1)]: Main: DBT_DEVICEARRIVAL
2013-01-10 01:30:48.993164 [Info.][MediaPortal(1)]: Main: Device Name: Generic Non-PnP Monitor
 
2013-01-10 01:30:49.009765 [Info.][MediaPortal(1)]: Main: DBT_DEVICEARRIVAL
2013-01-10 01:30:49.010742 [Info.][MediaPortal(1)]: Main: Device Name: Generic Non-PnP Monitor
 
2013-01-10 01:30:49.444336 [Debug][MediaPortal(1)]: Main: WM_DISPLAYCHANGE
2013-01-10 01:30:49.444336 [Info.][MediaPortal(1)]: Main: Resolution changed to 850x1028x32 or displays added/removed
 
2013-01-10 01:30:53.914062 [Debug][MediaPortal(1)]: Main: WM_DISPLAYCHANGE
2013-01-10 01:30:53.914062 [Info.][MediaPortal(1)]: Main: Resolution changed to 1920x1028x32 or displays added/removed

Again Windows is not consistent. When the resolution gets larger it doesn't see a DEVICEREMOVECOMPLETE nor a DEVICEARRIVAL. No wonder we have different behaviour on different machines.

But this inconsistency seems only to apply to GPUs...

Anyway. The DEVICEREMOVECOMPLETE of a display or audio device (in case of HDMI they probably are the same devices with different classes, haven't logged the classes yet) should be enough to simply stop playback preventing an empty audio stream in Direct Show.

And for specific audio renderers we can put in different treatments later. Probably MPAR will make use of this. As I am only bitstreaming I hand this over to @tourettes once this change is in master.

Resolution stuff is handled by WM_DISPLAYCHANGE as before but now also verified in WM_GETMINMAXINFO as well. Just as a precaution to catch the parts where the GPU isn't yet fully ready. If this is not enough I set the form bounds in WM_WINDOWSPOSCHANGED, WM_MOVE, WM_SIZE also for fullscreen.

Doesn't break anything doing it multiple times. If the value is already the same a form will do nothing.

One of these message would come late enough when the GPU is ready to catch the the few times where windows says the resolution changed but in fact it didn't yet. I don't want to put in some kind of Thread.Sleep() here.

I just put it in every window size/position related message. That should be enough. I am so sick and tired of this inconsistent behaviour. OK, GPU drivers are largely responsible for such inconsistent behaviour.

If this is still not enough and we find a setup that still has an occasional "half screen", I put it in the render loop and be done with GPU drivers forever.

Next Build on the weekend: I'll try to work on the suspend/resume stuff as well before the next round of tests.

 

[Scythe42]

New Build is up. Please test and report any issues you find.

Beside looking if there are still scenarios where you see a "small MP screen" please also focus on resume/suspend scenarios and playback.

 

[infinite.loop]

New Build is up. Please test and report any issues you find.

Beside looking if there are still scenarios where you see a "small MP screen" please also focus on resume/suspend scenarios and playback.

Should this work in combination with RefreshRateChanger?

 

[Scythe42]

Yes.

XP compability is currently only broken. But as already pointed out, special handling will be added in end again.

 

[FreakyJ]

I tested it and it works like a charm

- starting MP over RDP - OK
- start MP session via RDP and than go in front of the real monitor - OK
- start MP in front of the real monitor - OK
- switching between Fullscreen, Windowed mode, MiniPayer - OK
- mouse hiding - OK
- sleep while MP is in windowed mode and wake up again - OK
- start MP (fullscreen) -> sleep -> wake up - OK (logs attached if you're interested )

I couldn't test something HDMI related because my test PC has no HDMI and my HTPC is on a custom MP 1.2.0 build with my own Half Fullscreen workaround

 

[Scythe42]

Any tests are welcome as there are sure a few glitches that need to be sorted out.

 

[edterbak]

Scythe, WHAT DID YOU DO?!? I get extremely good results on this one.
The results.
A Normal on/off toggle.
Perfect. Fast response back. No black screens, minimized stuff.

B Very quick on/off toggle of the display in a row
Perfect. Fast response back. No black screens, minimized stuff.

C Full RDP/VNC/Teamviewer testing also needed

D AsRock InstantBoot test ( Dont have an ASrock board)

E Suspend/Hibernation and Resume tests.
Sleep+Hybernate, good results. MP comes back perfectly. No issues
Attached a separate log for this.

F Changing Themes or Skins in MP
No issue seen. No crash just a switch of skin.

G Switch off/on during playback
GOOD behaviour. Audio keeps going if tv only is off. (thats the way I like it!) Image comes back normally
This is even with making use of default direct3d renderer.

Dynamic refreshrate working OK
I once experienced minimzed playback start. See log for that instance.


Found issue's

• when playing audio file (mp3) and turn off/on receiver, MP crashes.
• timebar during playback isnt showing actual position but end only. This is in titan and DW. see screenshot.

Tested all in two goes: The attached files contain...
1 All tests except sleep/hybernate (with music playback crash on the end!)
2 Sleep/hybernate test.

@Scythe42
How do you prefer I attach logs. Like I did now with as much tests in one log? Or separate ones per tested item?