2017-11-30, 02:07 AM
I rebooted my HTPC at about 14:25 this afternoon. I had updated the firmware level on my HDHomeRun and during that process HDHomeRun detected that NextPVR was using some of its function, and asked if it could stop the NextPRV service. To make sure that there were no problems, I decided to do a reboot of Windows which would restart the NPVR Recording Service cleanly.
With the HDHomeRun firmware change, I thought a test to make sure that NextPVR could still access the tuner was appropriate , so I scheduled a recording from 15:00 to 16:00. The recording was fine. However, after the recording the HTPC didn't enter sleep which I would have expected it to - by 18:05 it was obvious it was not going to sleep. The only thing running on the system is NextPVR and then MCEBuddy from 23:45 to whenever it finishes early in the morning.
Unfortunately, like many Windows 10 users I have encountered the screen flickering problem following Windows sleep after the forced update to the fall 2017 Creators release. Only with a reboot of the system can I again see information on my monitor. So I had to reboot at 16:05 to be able to examine the NextPVR log to see what was going on. Hence the logs containing the times of interest are xxxxxx.log.1
When I examined NPRV.log1 and NRecord.log.1, I discovered that starting at about 16:20 this afternoon the system was going into standby and then waking about 1 minute and 10 seconds later. This is not the first time I have encountered this problem - when I researched the problem earlier this month I discovered that a solution that would prevent the problem was to restart the NPVR Recording Service frequently which I have been doing by rebooting the system.
Today I checked the Windows event log again using a filter I created earlier this month. I found the system is entering sleep due to 'Sleep Reason: System Idle', followed by a system waking message just over 1 minute later. The source of the wake up is 'Wake Source: Timer - NRecord.exe'. This is a repeating pattern with time stamps that closely match the 'System is going into standby' messages in the NPVR.log.1 and the 'Resuming...' messages in NRecord.log.1.
Questions:
1) When examining the NPVR.log.1 it appears that NextPVR is busy processing when Windows thinks the system is idle. After the recording finished shortly after 16:00, I have no idea what NextPVR was doing but it is clearly doing something per the logs until the first standby message at 2017-11-29 16:20:08.723.
2) Why did NextPVR wake the system at 2017-11-29 16:21:16.846 (The event log clearly states that it was a NextPVR timer that woke it).
3) Why does NextPVR and Windows enter a battle of trying to sleep the system and wake it after this first sleep / wake event?
4) Is NextPVR doing useful processing just before the sleep and after the wake? I ask as I don't recall NextPVR doing this sort of processing in other NPVR.logs I have looked at. Is it in some sort of a loop?
5) Is there a setting or another solution to prevent this? This experience tells me that stopping and starting the NPVR Recording Service as suggested by others in the NexpPVR forum is not a long lasting solution - the sleep / wake cycle started to occur only 2 hours after my reboot of Windows and after only one recording had been done.
Note: I have added one file to the LOGS directory under USER/PUBLIC/NEXTPVR/LOGS before zipping it. It is called 'Sleep - wake events ....' and is an extract of the Event Log on Windows containing the sleep and wake events from this afternoon. It can be viewed, including details of each event, with the Event Viewer Snapin from Windows.
Environment: Windows 10 plus fall 2017 Creators Update, NextPVR" version="4.0.4" buildDate="171121"
Electricity has become expensive in the Toronto area, and sleeping the HTPC when there is nothing to do is very important. Today's events suggest the stopping and starting the NPVR Recording Service nightly is not a solution. Since many others have encountered this, finding the root cause and developing a solution is important.
Thank You
With the HDHomeRun firmware change, I thought a test to make sure that NextPVR could still access the tuner was appropriate , so I scheduled a recording from 15:00 to 16:00. The recording was fine. However, after the recording the HTPC didn't enter sleep which I would have expected it to - by 18:05 it was obvious it was not going to sleep. The only thing running on the system is NextPVR and then MCEBuddy from 23:45 to whenever it finishes early in the morning.
Unfortunately, like many Windows 10 users I have encountered the screen flickering problem following Windows sleep after the forced update to the fall 2017 Creators release. Only with a reboot of the system can I again see information on my monitor. So I had to reboot at 16:05 to be able to examine the NextPVR log to see what was going on. Hence the logs containing the times of interest are xxxxxx.log.1
When I examined NPRV.log1 and NRecord.log.1, I discovered that starting at about 16:20 this afternoon the system was going into standby and then waking about 1 minute and 10 seconds later. This is not the first time I have encountered this problem - when I researched the problem earlier this month I discovered that a solution that would prevent the problem was to restart the NPVR Recording Service frequently which I have been doing by rebooting the system.
Today I checked the Windows event log again using a filter I created earlier this month. I found the system is entering sleep due to 'Sleep Reason: System Idle', followed by a system waking message just over 1 minute later. The source of the wake up is 'Wake Source: Timer - NRecord.exe'. This is a repeating pattern with time stamps that closely match the 'System is going into standby' messages in the NPVR.log.1 and the 'Resuming...' messages in NRecord.log.1.
Questions:
1) When examining the NPVR.log.1 it appears that NextPVR is busy processing when Windows thinks the system is idle. After the recording finished shortly after 16:00, I have no idea what NextPVR was doing but it is clearly doing something per the logs until the first standby message at 2017-11-29 16:20:08.723.
2) Why did NextPVR wake the system at 2017-11-29 16:21:16.846 (The event log clearly states that it was a NextPVR timer that woke it).
3) Why does NextPVR and Windows enter a battle of trying to sleep the system and wake it after this first sleep / wake event?
4) Is NextPVR doing useful processing just before the sleep and after the wake? I ask as I don't recall NextPVR doing this sort of processing in other NPVR.logs I have looked at. Is it in some sort of a loop?
5) Is there a setting or another solution to prevent this? This experience tells me that stopping and starting the NPVR Recording Service as suggested by others in the NexpPVR forum is not a long lasting solution - the sleep / wake cycle started to occur only 2 hours after my reboot of Windows and after only one recording had been done.
Note: I have added one file to the LOGS directory under USER/PUBLIC/NEXTPVR/LOGS before zipping it. It is called 'Sleep - wake events ....' and is an extract of the Event Log on Windows containing the sleep and wake events from this afternoon. It can be viewed, including details of each event, with the Event Viewer Snapin from Windows.
Environment: Windows 10 plus fall 2017 Creators Update, NextPVR" version="4.0.4" buildDate="171121"
Electricity has become expensive in the Toronto area, and sleeping the HTPC when there is nothing to do is very important. Today's events suggest the stopping and starting the NPVR Recording Service nightly is not a solution. Since many others have encountered this, finding the root cause and developing a solution is important.
Thank You
