[WiP] madVR support in MP1 (11 Viewers)

[alexdepalma]

V87 (added more log)

Channel change freeze
First tuned an SD channel, passed to HD one, and to another the SD with different card (sat). Mad Vr error process shown on the screens and lost of deinterlace. change to previous HD chanels/card on different group and freezed.

 

[kenwonders]

@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 ?

It has previously yes, I'll switch off Atmo for a bit and report how it is today (sorry Rick!)

Glad I did this today :
//const uint8_t header[3] = { 0xD7, 0xEE, 0x23}; //atmoduinov2
const uint8_t header[3] = { 0xFF, 0x00, 0x00}; //ambibox/atmoduino

 

[Sebastiii]

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.

Good but it seems that other users get a deadlock
About the blackscreen fullscreen/windowed i think it's because i decide to display all layers or because i change the order of this.
So yes always report it it's good and like this we can see if it's a deadlock code or wrong display (mp still reactive).

Best is to try with EVR with watchdog (also can be made with madvr mode too to confirm)

 

[Sebastiii]

V87 (added more log)

Channel change freeze
First tuned an SD channel, passed to HD one, and to another the SD with different card (sat). Mad Vr error process shown on the screens and lost of deinterlace. change to previous HD chanels/card on different group and freezed.

I can't reproduce it's a shame, i'm doing exactly the same, from IPTV card to DVB-S so act like release/add madVR so i should be able to reproduce it but not lol.
Also when doing stress test, (maybe you could tell me if it does the same) :

I've added to a playlist some video sample (no chapter in it) and after that i start to play and doing F8 to skip fast as i can between the playlist.
Sometimes it can get freezed when Tsreader need to render Audio Pin or into dsRotEntry (i'm trying to move the method differently).

The point is does a playlist can trigger also the deadlock of osdservice.

I would like result (if possible) between a playlist with VMR9 only (so only mkv for ex) and another one (with only .ts) and another one with mixed mkv/ts.

Thanks

 

[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 ?

It has previously yes, I'll switch off Atmo for a bit and report how it is today (sorry Rick!)

Glad I did this today :
//const uint8_t header[3] = { 0xD7, 0xEE, 0x23}; //atmoduinov2
const uint8_t header[3] = { 0xFF, 0x00, 0x00}; //ambibox/atmoduino

Best test would be to delete the plugin

 

[kenwonders]

@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 ?

It has previously yes, I'll switch off Atmo for a bit and report how it is today (sorry Rick!)

Glad I did this today :
//const uint8_t header[3] = { 0xD7, 0xEE, 0x23}; //atmoduinov2
const uint8_t header[3] = { 0xFF, 0x00, 0x00}; //ambibox/atmoduino

Best test would be to delete the plugin

Plugin gone for now, pretty sure it's not the cause of the freeze though. Will get a debug later.

 

[Rick164]

Most likely the reason for AtmoLight crashing on the C++ side (AtmoDXutil) is that the surface is empty, patched AtmoDXutil and send to Ken and if that solves it will handle that case in the plugin as well so that it doesn't reach that point if the surface is invalid.

 

[kenwonders]

Ok one hang report coming up, no AtmoLight running during debug. Here's the 2 threads in regards to dshowhelper:

Not Flagged 4156 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()

Not Flagged 2784 0 Worker Thread madVR.ax thread dshowhelper.dll!CCritSec::Lock Highest
ntdll.dll!_NtWaitForAlertByThreadId@8()
ntdll.dll!@RtlpWaitOnAddressWithTimeout@16()
ntdll.dll!RtlpWaitOnAddress()
ntdll.dll!RtlpWaitOnCriticalSection()
ntdll.dll!RtlpEnterCriticalSectionContended()
ntdll.dll!_RtlEnterCriticalSection@4()
dshowhelper.dll!CCritSec::Lock() Line 50
dshowhelper.dll!CAutoLock::CAutoLock(CCritSec * plock) Line 98
dshowhelper.dll!MPMadPresenter::ClearBackground(const char * name, __int64 frameStart, tagRECT * fullOutputRect, tagRECT * activeVideoRect) Line 240
madVR.ax!4a48954f()
[Frames below may be incorrect and/or missing, no symbols loaded for madVR.ax]
madVR.ax!4a49b316()
madVR.ax!4a4eafe8()
madVR.ax!4a4eafe8()
madVR.ax!4a4eb084()
madVR.ax!4a4e8f7f()
madVR.ax!4a4c146a()
4b71d2b4()
4b71d2bc()

Looks like another madpresenter reference, not one seen before. Logs in a minute when I get to the TV machine.[DOUBLEPOST=1464444495][/DOUBLEPOST]Logs logs logs. Looks like destructor code didn't get to run at failure.

 

[daWooky]

hi guys,
tested v87 with client, i get some new funky zapping effects sometimes


frezzebug is still there,log explained;
first watched some files then tv, zapped on some various programs - the blackscreen with mepo still active in back happend two times (madfrezze 1 + 2); then i continued some zapping (only a few) - tada,mepo really unresponsive, deadlock (madfrezze 3)

The point is does a playlist can trigger also the deadlock of osdservice.

I'll try it later, cl finalday

firsthalf edit: yep, playlist can trigger a deadlock
client playlist run was without .ts files
it was running for 30min aaa and i just realised i forgot the madfreeze, damn

 

[Sebastiii]

Here we go V89