Recording Service will not start with windows after upgrade to windows 10 from 7

[dixxfixx]

At the bottom of that log file, six recordings are marked as service not running. Just above that, where there are wakeups being scheduled for those recordings, the times are already in the past. Is that normal? (Still trying to learn log-ese.)

[sub]

There is no sign of any errors in those logs. There is some unaccounted for time, which are gaps between those logs. We can't tell what happened in those gaps. ie, was the machine turned off? If the recording service had crashed, we would hopefully have seen some error in the logs, but I can't see anything obvious. Any messages in the Windows Event Viewer indicating the recording service crashed?

[mvallevand]

Yeah, the logs look like it's starting fine.

They aren't stopping fine though.

Martin

[sub]

They aren't stopping fine though.

Where in the logs? I don't see what you're talking about.

[mvallevand]

NRecord when shutting down cleanly should have an OnStop() and About to stop webserver.

Martin

[sub]

Yes, if it was shutdown cleanly, but the absence of these messages doesn't identify NextPVR as the causing any problem though. They'd need to look for me info, like messages in the event viewer etc.

[mvallevand]

I didn't mean to imply a problem I'd hazard a guess that the PC is just being shutdown and not put to sleep.

Martin

[sub]

Ok. Yeah, I suspect something like this too.

[lynx]

The big difference between Windows 10 and previous versions is that when services fail to respond, Windows 10 eventually seems to kill them off (probably after a couple of attempts without response, I haven't seen the details on this).

So the problem may be that the service doesn't have a method of responding to service queries. This is a common failing made by programmers who don't realise the importance of this when writing services, and think that telling the service manager that it is active is sufficient. I used to make this error so I know it is easy to overlook. It is particularly important on slow or busy systems, which is usually the case at system startup.
Increasing the wait_hint might also help, 2 seconds is quite short, I've often seen the service take 5 or 6 seconds before it shows up as running, even at times other than startup.

Those are ideas for the programmers, but there are a couple of suggestions users can try until the problem is fixed:

1) Change the startup type to Automatic (Delayed Start).
2) Set the recovery options to restart the service on the first and second failures, reset the count after 1 day and restart the service after 1 minute.

Automatic (Delayed Start) waits 2 minutes (default) after all the other Automatic services have started.

These settings should give the system time to settle down after startup, and may help in the case of other failures.
I don't recommend changing the option for subsequent failures, that could cause severe problems in the case of a genuine fault.

The recording service failed consistently before I changed these settings but I haven't yet had chance to check whether this is a permanent solution. So far it seems to work but I've lost too many recordings in recent days to ignore it any longer.

[dcpaschal]

I was using WMC in W7 and upgraded to NextPVR and W10 after continued issues with the WMC EPG. I upgraded to W10 first, and then installed NextPVR. I also experienced the issue of the recording service not starting when I would restart the computer.

Changing the recording service startup options as described below seems to have solved the issue for me.

The big difference between Windows 10 and previous versions is that when services fail to respond, Windows 10 eventually seems to kill them off (probably after a couple of attempts without response, I haven't seen the details on this).

So the problem may be that the service doesn't have a method of responding to service queries. This is a common failing made by programmers who don't realise the importance of this when writing services, and think that telling the service manager that it is active is sufficient. I used to make this error so I know it is easy to overlook. It is particularly important on slow or busy systems, which is usually the case at system startup.
Increasing the wait_hint might also help, 2 seconds is quite short, I've often seen the service take 5 or 6 seconds before it shows up as running, even at times other than startup.

Those are ideas for the programmers, but there are a couple of suggestions users can try until the problem is fixed:

1) Change the startup type to Automatic (Delayed Start).
2) Set the recovery options to restart the service on the first and second failures, reset the count after 1 day and restart the service after 1 minute.

Automatic (Delayed Start) waits 2 minutes (default) after all the other Automatic services have started.

These settings should give the system time to settle down after startup, and may help in the case of other failures.
I don't recommend changing the option for subsequent failures, that could cause severe problems in the case of a genuine fault.

The recording service failed consistently before I changed these settings but I haven't yet had chance to check whether this is a permanent solution. So far it seems to work but I've lost too many recordings in recent days to ignore it any longer.