[WiP] madVR support in MP1 (7 Viewers)

[kenwonders]

Strange, that's what I thought was running, certainly the dshowhelper i built at lunch is used, but it must not have that commit in it

EDIT: Rebuild has produced a different sized file... sorry Seb will grab fresh info.

 

[joecrow]

MP Logs attached for couple of freeze ups. Sorry no madvr freeze report can't find a break key on my KB

 

[Sebastiii]

MP Logs attached for couple of freeze ups. Sorry no madvr freeze report can't find a break key on my KB

Hi, it's freeze or more black screen but MP is reactive (like alt+enter or what ever), a deadlock or full freeze, need MP to be killed
It's just to be sure because from your log, it seems that it didn't deadlock on Osdservices

 

[Sebastiii]

Strange, that's what I thought was running, certainly the dshowhelper i built at lunch is used, but it must not have that commit in it

EDIT: Rebuild has produced a different sized file... sorry Seb will grab fresh info.

Maybe this time we didn't deadlock

 

[kenwonders]

Something bad happened, remember that photo I took a while back of the low res screen?
It happened during a channel zap, I was able to stop TV, but restarting it produced the same low res image and a hang

Here's what was happening at the hang for dshowhelper:

Not Flagged 1104 0 Worker Thread msvcr120.dll!_threadstartex dshowhelper.dll!CAMEvent::Wait Below Normal
ntdll.dll!_NtWaitForSingleObject@12()
KernelBase.dll!_WaitForSingleObjectEx@12()
KernelBase.dll!_WaitForSingleObject@8()
dshowhelper.dll!CAMEvent::Wait(unsigned long dwTimeout) Line 128
dshowhelper.dll!LogThread(void * param) Line 259
msvcr120.dll!_callthreadstartex() Line 376
msvcr120.dll!_threadstartex(void * ptd) Line 354
kernel32.dll!@BaseThreadInitThunk@12()
ntdll.dll!__RtlUserThreadStart()
ntdll.dll!__RtlUserThreadStart@8()

Logs on way

 

[kenwonders]

Here be logs. There was a crash on tv video start on my first test too so that's in there as well as problem above.

 

[Sebastiii]

Hi
Ok so it seems that it didn't freeze on Osdservices at least (i think lol)
But in mad.log, i notice :

[2016-05-28 00:15:32,216] [ 0] [17cc] - MPMadPresenter:etDevice() pD3DDev 0x:2f2f1ec0
[2016-05-28 00:15:32,360] [ 0] [17cc] - MPMadPresenter:etDevice() pD3DDev 0x:0

[2016-05-28 00:15:15,731] [ 0] [138c] - MPMadPresenter:etDevice() pD3DDev 0x:2bbcc040
[2016-05-28 00:15:15,784] [ 0] [138c] - MPMadPresenter:etDevice() pD3DDev 0x:0

It's like the SetDevice is set to 0 directly after being set, no clue but it can cause what you have seen.

 

[Sebastiii]

@kenwonders can you try with watchdog first option to be sure, the log from madvr - crash report seems to be linked to AtmoLight :
19211965 +0075 AtmoDXUtil.dll _VideoSurfaceToRGBSurfaceExt@24

So does it happen wit stock default plugins too ?

 

[Sebastiii]

V87 (added more log)

 

[joecrow]

Hi, it's freeze or more black screen but MP is reactive (like alt+enter or what ever), a deadlock or full freeze, need MP to be killed
It's just to be sure because from your log, it seems that it didn't deadlock on Osdservices

I confirm that MP is still partially reactive, did not try alt+enter but toggle to fullscreen/windowed worked and returned MP tonormal working order, i.e. you are correct I did not have to kill MP.

I note that there are a couple of posts in the general support forum reporting black screen and freeze ups. I can't help but wonder if released 1.14 is not completely free of this problem.