MP crashes sometimes after resume from Standby (1 Viewer)

[michael_t]

Yep by looking log :

[2014-04-13 21:57:53,756] [Error  ] [PowerBroadcast Thread] [ERROR] - VMR9: Dispose() from wrong thread

The message is clear

Wow, that's clear enough! Well, the only consequence I see, is to cancel the work on the PowerBroadcast thread (which I did not like really...) and return to the basic solution. This works well for Win7 and Win8 unless there is a (significant) delay configured for resume. So I would suggest to get rid of the delay resume option. Why do we need it? If I am right, only to work around a problem with some audio devices (notably HDMI audio) that take longer time to restore after a resume. If this is the only reason for the delay resume option, we should try to fix the cause and no longer try to provide workarounds for the workaround...

Michael

 

[Sebastiii]

I'm agree we need to fix Audio source issue for sure
Can't we tell to windows to not go in standby until MP finish to run the standby source code ?
(I mean when i use VS, the suspend code is bypassed or message are sent in quite sync (when resume) and lead to MP freeze, so i'm sure it can happen too in normal usage (something slow happen and not all the code are executed correctly and then -> boom).

So to summarize :
1- Sequence need to done correctly. (the first approach was to use threadmessage, so working on main thread but i was thinking your rework should work also on main thread but it seems not).
2- Try to delay Windows suspend/standby process until MP code finish his job. (I think it can be possible, because sometimes when i set to suspend my PC, it don't want because some tool/hardware hold it, so it should be possible to delay it right ?)
3- Fix Audio issue (HDMI most of the time) when audio device is removed / added.

I think yes the resume option is to let hardware/software etc be ready.
For example here on my Win8.1, the network is not fully ready on wakeup (i can see trillian and Co not connected) so i think this option can be usefull in some case (it it's network related to let all ready before to try to connect to TVServer for example in multiseat)

 

[blub]

That does sound like a good plan

 

[blub]

Ok now since 1.7 final is out:

1) Will the thread stay here or will it be moved/removed/renamed
2) Once some coding is done on that topic will there be test-build on the 1.7 basis or will it most likely be on 1.8 - the latter would mean that I will only be testing when 1.8 pre will be out cause I kinda need a mostly running system

 

[Sebastiii]

Surely move it to the new section

 

[blub]

Hi

Version 1.7 final seems to run very smooth no crashes so far. I could get used to it

 

[skorz]

I can confirm that i have no crash in mp1.7 final too (AFTER i set volume to master instead of wave!)

 

[HomeY]

You guys are making me smile

 

[blub]

Ok I don't know if/what you guys changed since the WIP build I tested but I have no issues in 1.7.x final with the settings I am using.
I think the issue is resolved.

For anyone who stumbles across this in the future:

MP delay 8-10s
Volume set to Master
HDMI override (to prevent "no Audio issue" - did not impact on MP resume from STB crash frequency I think)