MP hangs when scheduled recording starts. (2 Viewers)

[joecrow]

Have you checked the cause? It could be something as simple as EPG grabbing...

You are right, I will investigate that further. (Tomorrow)

Again, I think you're assuming that normal behaviour is for recordings to be done in away mode. With the greatest respect, that assumption needs to be confirmed before you can say that something is not right.

Yes very true it is an assumption but I can't believe I am the only one who does not expect or want the TV lighting up for an unatended recording. Come on people is there anyone out there who can confirm or deny this, Win 7, 8.* or 10?

Regards
Joe

 

[Tuomaa]

I took a quick look of the log files and for MP 1-1 everything seems to be as it should.

For MP1-2, the reason why CECRemote is not waking the devices is the same as mentioned in the CECRemote thread, the plugin is not receiving the APMRESUMESUSPEND message. I'm not sure if this is because of the plugin or not, but it has worked before. Also the very first thing that CECRemote should do after receiving that message is to write a log message:
"CecRemote: PowerControl: User input detected after sleep (APMRESUMESUSPEND)". I'm currently little busy, but I will look more in to this later this week.

@joecrow

 

[mm1352000]

@Tuomaa
Thanks for your analysis.

As you can see from the log file, the events that MediaPortal receives from Windows in the MP1-2 case are:

1. [2016-03-13 11:07:05,020] [Log ] [MPMain ] [INFO ] - Main: WM_POWERBROADCAST (PBT_APMRESUMEAUTOMATIC)

2. [2016-03-13 11:07:10,050] [Log ] [MPMain ] [INFO ] - Main: WM_POWERBROADCAST (PBT_POWERSETTINGCHANGE)
...
[2016-03-13 11:07:10,050] [Log ] [MPMain ] [INFO ] - Main: The display is on

3. [2016-03-13 11:09:10,753] [Log ] [MPMain ] [INFO ] - Main: WM_POWERBROADCAST (PBT_POWERSETTINGCHANGE)
[2016-03-13 11:09:10,769] [Log ] [MPMain ] [INFO ] - Main: User is providing input to the session

So, Windows never sends WM_POWERBROADCAST + PBT_APMRESUMESUSPEND message that you mentioned. Of course Windows should have sent that message... but from experience with many similar reports from various people, it has become obvious that we can't assume that message will be sent/received. Perhaps there's a driver problem or rogue application on these people's systems. I don't know...

Anyway, if you look at the MP code you will see that MP now recognises that Windows failed to send the message. We attempt to generate the message that Windows should have sent for all the plugins that have WndProc()s:
https://github.com/MediaPortal/Medi.../MediaPortal.Application/MediaPortal.cs#L2036

If CEC Remote does not have a WndProc, it obviously won't receive the message from MP. In that case I recommend CEC Remote code to detect the situation in the same way that MP does (by detection of WM_POWERBROADCAST + PBT_POWERSETTINGCHANGE + GUID_SESSION_USER_PRESENCE).

I hope that helps.

 

[mm1352000]

After looking at the CEC Remote code, I see it has a WndProc(). Therefore it should be receiving the message from MP.

@Sebastiii
I think this change from you has broken plugin messaging:
https://github.com/MediaPortal/MediaPortal-1/commit/f45db6283c281e9edb25bc2e905a4e9d02ca64d6

In particular, this line:
https://github.com/MediaPortal/Medi...d6#diff-393471767838c7b3839e28d1fd5f7af7R2071

WndProc() must be able to handle multiple messages simultaneously! Therefore you cannot use a single global variable _wndProcPluginExecuted for tracking whether WndProc() was executed.

For example (from the log file)...
1. WM_POWERBROADCAST message received. Handling starts.
[2016-03-13 11:09:10,753] [Log ] [MPMain ] [INFO ] - Main: WM_POWERBROADCAST (PBT_POWERSETTINGCHANGE)

2. WM_ACTIVATE message received. Handling starts. WM_POWERBROADCAST is still being handled!
[2016-03-13 11:09:10,800] [Log ] [MPMain ] [DEBUG] - Main: WM_ACTIVATE (WA_ACTIVE)

3. WM_ACTIVATE message handling is completed. WndProcPlugin() is called, so _wndProcPluginExecuted is set true.

4. WM_POWERBROADCAST message handling is completed.
[2016-03-13 11:09:10,800] [Log ] [MPMain ] [INFO ] - Main: OnResumeSuspend - Done
[2016-03-13 11:09:10,815] [Log ] [MPMain ] [DEBUG] - Main: Providing input - suspended is false

WndProcPlugin() is called, but _wndProcPluginExecuted is already true from (3). BUG!


To be clear: in this example, PluginManager.WndProc() will only be called for WM_ACTIVATE. After that, _wndProcPluginExecuted will be set true => blocks PluginManager.WndProc() for WM_POWERBROADCAST.

IMHO this change must be reverted or fixed urgently for 1.14. JIRA reopened...

 

[mm1352000]

4728 branch updated.
https://github.com/MediaPortal/Medi...-BUG-Don't_display_OFF_and_ON_cycle_on_resume

@Sebastiii

 

[Sebastiii]

Thanks m8

Are you sure about multiple messages simultaneously ?
I remember talking with @michael_t and Tourettes about it and i think remember that that should be done in sync (one thread or something) i remember that they link me to MS website. But maybe i'm wrong about and my memory is surely not good lol.

I think it was on IRC and i'm not sure about the log

But for sure, i'm trusting you too because you are a very good dev

 

[mm1352000]

Are you sure about multiple messages simultaneously ?

Yes, currently we are receiving/handling multiple messages simultaneously. I don't know if that is right, wrong, weird, normal or otherwise... but we definitely must pass all messages to plugins. So, unless and until locking is added (=> receive/handle one message at a time), the code change needs to be reverted.

 

[Sebastiii]

I think we should merge the branch (the revert) and i have merge your reverted branch
So it could be nice to know the right behaviour, does this need to be handle one message at the time, i think yes, i will try to find the ms doc or something
Thanks

 

[mm1352000]

i will try to find the ms doc or something

Yes, please do. I know that normally all manipulation of UI controls needs to come from the thread that created them. However I never heard of WndProc() calls needing to be handled synchronous.

 

[joecrow]

Regarding the issue I had with MP not idling back to sleep it may have been a Windows problem, "Standby prevented by Fileserver (driver) svrnet" (or something like that) which is a known problem with Home Group usage, it was very persistant, survived a restart and I could only get rid of it by disabling/enabling the Network adaptor. I should no longer trouble me again as I have taken the HTPC out of the Home Group, I was not using it anyway because for other reasons I need to have IPv6 disabled. I am not 100% sure that was the only issue but I had to cut short any further troubleshooting as I can into audio problems with .mkv using MPAR and reverted back to 1.13 to resolve it.
Please let me know when you have anything new I can test for a resolution for the original problem.