Bug in PowerScheduler -- shutdown just before recording (1 Viewer)

[dero]

MediaPortal Version: SVN 20.3.2007
MediaPortal Skin:
Windows Version:
CPU Type:
HDD:
Memory:
Motherboard:
Motherboard Chipset:
Motherboard Bios:
Video Card:
Video Card Driver:
Sound Card:
Sound Card AC3:
Sound Card Driver:
1. TV Card:
1. TV Card Type:
1. TV Card Driver:
2. TV Card:
2. TV Card Type:
2. TV Card Driver:
3. TV Card:
3. TV Card Type:
3. TV Card Driver:
4. TV Card:
4. TV Card Type:
4. TV Card Driver:
MPEG2 Video Codec:
MPEG2 Audio Codec:
Satelite/CableTV Provider:
HTPC Case:
Cooling:
Power Supply:
Remote:
TV:
TV - HTPC Connection:

I maybe found some bugs in the TVServer-PowerScheduler.

--

Scenario 1:

In NextWakeUpTime, the earliest wakeup time is _lastIdleTime + IdleTimeout. Assume the system was idle for 2 minutes and IdleTimeout is set to 8 minutes. The next recordng wants to start in 5 minutes. When the user tries to hibernate the system, _idle is true and OnPowerEvent does not block the QuerySuspend request. The system is going to hibernation and misses the recording since the next recording wants to start prior to earliest wakeup time (which is not allowed in NextWakeUpTime).

Scenario 2:

The system was idle for 2 minutes and IdleTimeout is set to 8 minutes. The next recording wants to start in 8 minutes and 1 second. Just when the system is about to shutdown, the timer is raised, but may not be fast enough to unset _idle, thus this recoring and all future recording are missed.

--

Generally, the PowerScheduler should disallow shutdown when a recording is "about to begin", i.e. there should be a DisallowTimeout, which says how many minutes before the next event is due, a shutdown is disallowed.

Regards,

dero

 

[scoop]

Hi dero,

First of all, thanks for your comments and thoughts.

About scenario 1: "when the user tries to suspend the system" is currently not supported (as stated in the wiki). Then, if system is idle for 2 minutes and schedule is due within idle timeout, nothing would go wrong. This is why the earliest possible wakeup time is calculated based on _lastIdleTime + IdleTimeout. BTW, although the code might be there, OnPowerEvent will unfortunately never block any suspend request (.NET CLR bug by design).

There is indeed a slight chance that scenario 2 would cause a recording to fail when it's scheduled just around the time PS wants to hibernate the system. To avoid this I already intend to write a handler which will indeed disallow shutdown if a schedule is almost due. I assume using the idletimeout as base for calculation would suffice.

Kind regards,
Michel

 

[dero]

Hi Michel,

About scenario 1: "when the user tries to suspend the system" is currently not supported (as stated in the wiki). ... BTW, although the code might be there, OnPowerEvent will unfortunately never block any suspend request (.NET CLR bug by design).

That's a pity because this SHOULD be supported. Maybe, we can use the client plugin to route the QuerySuspend request from the MP-main-window down to the server and back? Or, create a hidden window in the service itself (may be not allowed for services).

It should be like that: When the users tries to shutdown the system and PS is not idle, it should block the request and hibernate instantly when the system becomes idle again (recording stops) and no recording is due. I.e. there is a flag: ShutdownAsSoonAsIdle.

However, we have take in account: User pushes hibernate, PS blocks (because records), one hour later, user comes back, sees PC is still active, goes to TV, meanwhile the recording stops, comes back to homescreen (idle). Now PS should not immediately shutdown. So, when we recognize user interaction, we should reset the ShutdownsAsSoonAsIdle flag.

There is indeed a slight chance that scenario 2 would cause a recording to fail when it's scheduled just around the time PS wants to hibernate the system. To avoid this I already intend to write a handler which will indeed disallow shutdown if a schedule is almost due. I assume using the idletimeout as base for calculation would suffice.

You say that a shutdown could not be allowed idletimeout minutes before the next recording starts. That's not good IMHO. Assuem idleto is set to 20 minutes. Recording is set to start in 40 minutes and user leaves the PC. Then the PC stays one until the recording starts, but could easily go to shutdown for about 20 minutes and save power.

Or the other way: idleto is set to 1 minute. prewake to 2 minutes. PC is idle with a recording to start in 2 minutes, PC is shutdown for 1 minute. Could it be that wakeup fails then again (i.e. when shutdown progress takes awhile)?

I would prefer an extra parameter saying, how many minutes before the next event is due any attempt to shutdown the PC should be blocked.

Regards

dero

 

[scoop]

Hi dero,

Well, it's released as an early beta so don't expect it to be feature-complete already. Of course delegating suspend/resume should be possible from MP and that is on my todo list. Any improvements (submitted as patches on SF) are of course greatly appreciated.

Kind regards,
Michel

 

[dero]

Hi Michel,

Well, it's released as an early beta so don't expect it to be feature-complete already. Of course delegating suspend/resume should be possible from MP and that is on my todo list. Any improvements (submitted as patches on SF) are of course greatly appreciated.

Kind regards,
Michel

even so it's already a good piece of work!

If you're not going to implement the issues within the next 7 days, I might try to do it...

Regards

dero

 

[dero]

Hi Michel,

in another forum, I found code to workaround the QueryFailed problem.

http://www.pcreview.co.uk/forums/thread-2613353.php


---------------------
Work-Around Code:
---------------------
public class Service : System.ServiceProcess.ServiceBase

{

public Service()

{

// Find the initialisation routine - may break in later versions

MethodInfo init = typeof(ServiceBase).GetMethod("Initialize",
BindingFlags.NonPublic | BindingFlags.Instance);

// Call it to set up all members

init.Invoke(this, new object[] { false });

// Find the service callback handler

FieldInfo handlerEx = typeof(ServiceBase).GetField("commandCallbackEx",
BindingFlags.NonPublic | BindingFlags.Instance);

// Read the base class provided handler

m_Forward = (Delegate)handlerEx.GetValue(this);

// Create a new delegate to our handler

Delegate test = Delegate.CreateDelegate(m_Forward.GetType(), this,
"ServiceCallbackEx");

// Install our handler

handlerEx.SetValue(this, test);

// This call is required by the Windows.Forms Component Designer.

InitializeComponent();

}

private int ServiceCallbackEx(int command, int eventType, IntPtr eventData,
IntPtr eventContext)

{

// Call the base class implementation which is fine for all but power and
session management

if (13 != command) return (int)m_Forward.DynamicInvoke(command, eventType,
eventData, eventContext);

// Process and forward success code

if (OnPowerEvent((PowerBroadcastStatus)eventType)) return 0;

// Abort power operation

return 0x424d5144;

}

-------------

Regards

dero

 

[scoop]

Hi,

While this might seem a solution to actually be able to prevent the system from suspending when an external process wants to suspend the system, it also results in a (not so nice) popup indicating "a service has prevented the system from suspending". This is obviously not what you want to happen when running MP. Onfortunately there is no silent workaround AFAIK.

Kind regards,
Michel

 

[dero]

Hm, that's true. However, you also don't want your PC to shutdown while recording...

What if a windowed-app denies the query? Do you also get such a popup?

Regards

dero

 

[scoop]

Hi,

Any public SVN snapshot with rev#14110 or higher should fix the problem with nearly due recordings being missed.

Kind regards,
Michel

 

[dero]

Hi,

Any public SVN snapshot with rev#14110 or higher should fix the problem with nearly due recordings being missed.

What a pity! I've been working on the PS a lil bit in the last few days and implemented some things. I also fixed the "nearby-recording"-bug.

I will look at your changes, merge them into my working set, and then send you the "final" code via SF.

Regards

dero