[MP1-4578] Crashes after standby. (3 Viewers)

[Sebastiii]

Let's try to minimize MP and restore to see what happen on your system

 

[Sebastiii]

V17 added to previous post (so it try to minimize MP and restore on resume maybe GPU will be happy lol).

 

[Sebastiii]

From log, it seems that 10 minutes of standby can trigger the crash (even less sometimes) so no need to wait too long

 

[HTPCSourcer]

A minimize/restore mechanism would certainly be interesting. Let me test an extended resume delay first. If it's only that I need to wait a few seconds, so be it. I'll let you know.

 

[Sebastiii]

I will post V18 (minimize on standby and resume on wake up and also avoid to call change screen while resuming (WIP) but i notice that from V13 when windows doesn't send power message in correct order, i send wrong message to plugins, so i correct that too in V18).

So again quite testing to be done

And EDIT V18 attached.

 

[HTPCSourcer]

Test V16 + 30s delay: MePo is correctly resuming if given sufficient time. Upon resume one can see the Windows desktop with MePo in tray and shortly after full screen Titan home comes back. This would work for me and probably I can cut out a few more seconds of the delay, but that's not going to make a big difference. I will continue to monitor this for sustainability.

The interesting point now is to better understand the behavior. The PC resume process - be it reestablishing the network device connection or, more importantly, the graphics driver setup - is not fast enough to catch up with MediaPortal addressing DirectX functions. Therefore setting a delay is not a bad solution, although not the most esthetic one either, and the question is if there is any system information that would flag readiness to the system and that can be polled.

In essence I would suggest to you that you call it a done job at this point and that we

• Add your V16 status to the branch
• Create an entry in Wiki that addresses potential resume issues and recommends setting an adequate delay (e.g. 30s).

While there has been a problem, it does not seem to be that common that I would consider a 100% solution to be a top priority for you. The combination of V16 + delay is probably something like 90%+.

EDIT: log attached - I deleted masses of MusicInfoHandler error messages because of unresolved remote address

 

[HTPCSourcer]

I'll have a look at V18 over the next days.

 

[Sebastiii]

Could be nice if you can grab the log too (even on working one)
For sure V16 and under has a wrong information sent to plugins so maybe i will create a bin later (V19) with no minimize/restore on standby and only correct the message for plugins.

But will see you result with more V16 resume with delay

And i think you can trigger the issue all 10 minutes (based on event log ).

Current V2 branch is based on V18. But we need more test to confirm if it's better or not.
About a flag, MP receive it but the issue is when the driver crash, there is no way to MP to fully reinit from start (while running) and the only way is to restart MP. I didn't succeed to reinit MP while running, it seems the windows form didn't reupdate adapter etc.

Maybe WDDM is better or MP2 on this side

 

[HTPCSourcer]

Could be nice if you can grab the log too (even on working one)

I will add the log to the posting above this evening. Watch for it.

 

[killer8]

I tried twice today again and V16 is still rock solid for me. Is it recommended to try V18?