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

[HTPCSourcer]

Seb,

In that case it should be sufficient to just click into the MePo window, however, there is (was) no reaction to remote command even after clicking on the window. I'll check the Alt-Tab but recall that I had tried this before without success. Note that my own workaround made it necessary to select a menu AND a submenu entry. The latter doesn't match the lacking focus hypothesis.

 

[Sebastiii]

Ok so something different maybe but i just push another commit that will try to force focus after the resume so if you can try
BOT is building full installer and i will able to post another mp.exe too

 

[Sebastiii]

Here we go

 

[HomeY]

I will try to see if we can force a MP focus but normally it should be done automatically.

So enabling the option 'keep MediaPortal always on top' should also fix this problem? That would be a good test for you all to try then!

 

[HTPCSourcer]

Hi,

1. Enabling "Keep MP on top" doesn't solve the problem: putting MePo into standby via menu command and wake it up yields the same screen with the three exit Options frozen (as described above) and you have to either terminate MePo by using the mouse or play a couple of times with Alt-Tab
2. Seb's V2 fix did it

I still need to see how the remote behaves after a standard Windows-triggered standby but things are looking very good so far.

Thanks Seb!

 

[HTPCSourcer]

Good morning,

With Fix V2 the system is now waking up correctly and the remote is functional immediately.

One thing is strange though: I am using Titan Basic Home (Tile view) but MePo resumed in Classic view. Can this be due to the fix? I have now set Basic permanently in the Settings (Need to test if that helps) but it would certainly be better if the skin did not change views on its own.

 

[Sebastiii]

Hi

Nope the fix shouldn't change basic/classic view itself, the workaround to force the focus, was to minimize and restore MP (no clue why but that's only the 100% way to force the focus).

I already did that before in other MP part of code, but we need to test regression about :

1- What happen for MP when minimize to try is enable or minimize on exit.
2- Like step1 but with MP set/work in multi screen env.

I will try to do some test on my side but for sure will need help for testing that part

The good news, is that we can simulate it with sendmessage tools

 

[HTPCSourcer]

Not quite sure what you want me to do in step 1 and 2:

1 - Do you want me to Change Settings to "Minimize to tray upon Exit" and then Exit MePo?
2 - What is Multi Screen env?

Anyway, don't spend too much time for what may just be an artefact with different causes. I fixed the GUI/Titan to Basic Home, sent MePo into standby and woke it up immediately after: system returns in Basic home view. The real test will be to let Windows put the PC into standby and then wake it up again. I will monitor the behavior and report back here.

 

[Sebastiii]

I mean we need to test regression when using minimize to tray option.
I will try to do some adjustment and drop a new bin to test

 

[Sebastiii]

Ok, i think i cover all case

So you just need to look if it's ok on your side (your default setting), the update that i just make, should also unfreeze mp when mp is minimize when standby is happening and when wake up.

I think on my htpc (rarely) see MP minimize and didn't recover, it happen because windows handle was not correct and then the resume message was not send to the correct MP handle

So now this one should be fixed too (i hope) lol