MP1-4420: Potential Fix for the broken Startup Delay on resume (1 Viewer)

[HomeY]

Description of Change:
Delay on Resume is broken because of regression introduced in : MP1-4305.
This branch should fix this and also handle WM_POWERBROADCAST message in order, and not like now (It can be mixed, this mean suspend code and resume can be executed in the same time and can lead to MP freeze, it can also avoid to execute multiple time the same event (it can happen in rare case but can happen).

JIRA link: https://issues.team-mediaportal.com/browse/MP1-4420
Wiki link: http://wiki.team-mediaportal.com/REDIRECTS/MediaPortal.Configuration.Sections.GeneralStartupResume

Steps to install:
Download the >> Installer << and execute it. A future upgrade to the upcoming 1.9 Pre Release should be supported by this installer.

What/How to test:

1. Configure the start-up option, like described in the wiki (for example 30 secs) on MP start up and resume.
2. On MP start, MP should wait 30 seconds before start.
3. On MP resume (hibernate or other mode), MP should wait also 30 seconds (it will permit to some slow device to let time to start correctly).
4. Test also normal standby and resume (without using start-up options).

Please report back if it works for you or not!

TNX

** EDIT 2014-08-03 **
Updated installer link.

 

[michael_t]

Hi all,

I implemented a totally new fix for the problem which works fine for me (can even handle suspend while still waiting for delayed resume cleanly). Please give it a try.
The new branch is: MP1-4420_Delay_resume_is_not_working_correctly. A code review has been created (MP1CR-517).
To test the new code just replace 1.9 Pre-release MediaPortal.exe with the one provided in the zip file.

I tested the branch on Win7 with both sleep mode and hybrid sleep.
To be done yet:

• Test on Win8
• Test with hibernation (S4)
• Implement a dialog / splash screen indicating that MP is waiting to resume after wakeup (at the moment the screen is shown but unreactive)

Michael

PS: The solution in the previous post also came from me but is conceptionally buggy. So it makes not much sense testing it any longer

 

[Sebastiii]

Hi

For testing i use SendMessage tools that send :
Suspend :

Resume :

It seems the resume part didn't work (MP freezed) but if i send an (ResumeAutomatic) :

MP react and unfreeze.

I didn't test the delay yet but i thing something is not correct (on quick test) waiting news from wife @ hospital so maybe my test are not fully ok.

 

[Sebastiii]

Log from resumesuspend after suspend :

[2014-08-03 11:53:15,451] [Log ] [MPMain ] [DEBUG] - Main: OnSuspend - stopping playback
[2014-08-03 11:53:15,451] [Log ] [MPMain ] [DEBUG] - Main: SaveLastActiveModule - enabled False
[2014-08-03 11:53:15,451] [Log ] [MPMain ] [DEBUG] - Main: OnSuspend - stopping input devices
[2014-08-03 11:53:15,451] [Log ] [MPMain ] [DEBUG] - Main: OnSuspend - stopping AutoPlay
[2014-08-03 11:53:15,451] [Log ] [MPMain ] [DEBUG] - Main: OnSuspend - dispose DB connection
[2014-08-03 11:53:15,451] [Log ] [MPMain ] [INFO ] - Main: VideoDatabaseV5.db3 sqllite database cache flushed to disk.
[2014-08-03 11:53:15,452] [Log ] [MPMain ] [INFO ] - Main: OnSuspend - Done
[2014-08-03 11:53:24,067] [Log ] [MPMain ] [DEBUG] - Main: WM_POWERBROADCAST (PBT_APMRESUMESUSPEND)
[2014-08-03 11:53:24,067] [Log ] [MPMain ] [DEBUG] - Main: Wait for ResumeAutomatic / ResumeDelayed message

And nothing else after.

 

[Sebastiii]

Ok if we follow a real standby, it seems to work

 

[michael_t]

It makes no sense testing RESUMESUSPEND alone, since it always comes together with RESUMEAUTOMATIC. On Win7 RESUMEAUTOMATIC comes first to indicate that the system is resuming and then RESUMESUSPEND to indicate user activity. On Win8 the order of the both messages is changed, but the meaning remains the same. RESUMEAUTOMATIC may come alone if the system is waked up automatically (i.e. by a timer without user activity), RESUMESUSPEND can never appear alone without a previous RESUMEAUTOMATIC. Only if the user touches the system after it e.g. already woke up for recording there is a "lone" RESUMESUSPEND, but also in this case there was a RESUMEAUTOMATIC before (maybe long time before...).

So please combine the RESUMESUSPEND and the RESUMEAUTOMATIC messages or better use a real scenario (e.g. mapping power button to "sleep"/"hibernate", programming a recording) to test sleep / wakeup cycles.

Michael

 

[Sebastiii]

Yep real scenario or if i sent resumeauto and then resumesuspend is ok

 

[michael_t]

Then we still need a solution for informing the user that MP is waiting for resume. I tried various things and had no success:

• Switching the display off during the resume delay does not work very reliably (sometimes it works, sometimes it does not) and only makes sense if MP is run in fullscreen mode
• Showing a dialog - I did not manage to do so. The dialog was disabled at once and I don't know why...
• Showing a splash screen - The splash screen appeared but did not disappear. The MP client was blocked from the moment that it should resume...

Since I am no GUI programmer, I have no idea why all this did not work as it should. MP1-4420 is a bug fix and there was no message or whatsoever before, so why should we implement it now? But if someone has a good idea and can add a wait message to the MP1-4420 branch, this would be the icing on the cake

Michael

 

[Brudertac]

I have do some Tests with new Version ** EDIT 2014-08-03 ** and can say that Resume works fine.
There is no "Wait x Seconds" on Resume but the Wakeup behavior itself is very good.

We use this on our main HTPC so the next Days we will do more Tests

 

[HomeY]

There is no "Wait x Seconds" on Resume but the Wakeup behavior itself is very good.

This has never worked properly, except for fullscreen DefaultWide skin so it seems.
Let's fix the resume first, then the rest