Recording fails after unlocking PC

[mshuttle]

Hi,

I've been using NextPVR for many years now and recently took the decision to upgrade to version 5. I like it very much but I've been having some problems with it terminating recordings early.

It's taken me a little while to work out when it's happening, but it seems that sometimes, after my Windows PC has screen locked, when I sign back in the recording stops. I noticed this today when returning to my PC and unlocking it, expecting Hawaii 5-0 to be recording, the npvr notification icon was green rather than red. Checking the log file (below) I can see that the recording started fine at 18:55 (I do five minutes before, 10 minutes after as standard), but it was when I logged in at around 19:55 (irritatingly 5 mins before the end!) that the recording shutdown, and the log notes it got a 'GET request: /shutdown' at this point.

Code:

[...startup]
2020-06-29 18:55:00.165    [DEBUG][1]    Args...
2020-06-29 18:55:00.166    [DEBUG][1]     -listen:51994
2020-06-29 18:55:00.166    [DEBUG][1]     -type:DVB-T
2020-06-29 18:55:00.166    [DEBUG][1]     -device:Hauppauge WinTV 885 DVBT Tuner/Demod
2020-06-29 18:55:00.166    [DEBUG][1]     -instance:1
2020-06-29 18:55:00.166    [DEBUG][1]     -parent:14408
2020-06-29 18:55:00.166    [DEBUG][1]    Starting web server on port: 51994
2020-06-29 18:55:00.203    [DEBUG][1]    Found parent process: NextPVRServer
2020-06-29 18:55:00.204    [INFO][4]    Got POST request: /stream/start?slipseconds=1200&target=M%3A%5COff-Air%5CHawaii%20Five-0%5CHawaii%20Five-0_20200629_19002000.ts
2020-06-29 18:55:00.205    [DEBUG][4]    Starting Stream: M:\Off-Air\Hawaii Five-0\Hawaii Five-0_20200629_19002000.ts
2020-06-29 18:55:00.205    [DEBUG][4]    SlipSeconds: 1200
2020-06-29 18:55:00.205    [DEBUG][4]    Tuning:
<tuning>
  <type>DVB-T</type>
  <locator>
    <frequency>554000</frequency>
    <bandwidth>8</bandwidth>
  </locator>
  <service_id>22208</service_id>
  <tsid>20544</tsid>
  <onid>9018</onid>
  <service_type>1</service_type>
  <provider></provider>
</tuning>

2020-06-29 18:55:00.229    [DEBUG][4]    StartStream(): M:\Off-Air\Hawaii Five-0\Hawaii Five-0_20200629_19002000.ts
2020-06-29 18:55:00.277    [DEBUG][4]    Using tuner: Hauppauge WinTV 885 DVBT Tuner/Demod (1)
2020-06-29 18:55:00.277    [DEBUG][4]    About to connect...
2020-06-29 18:55:00.277    [DEBUG][4]    has network provider
2020-06-29 18:55:00.278    [DEBUG][4]    has tuner
2020-06-29 18:55:00.299    [INFO][4]                [4b4332e6-c822-11db-beb400a0c9f21fc7]-00080000-00000000
2020-06-29 18:55:00.299    [DEBUG][4]    About to auto detect capture filter...
2020-06-29 18:55:00.300    [INFO][4]    Need match: [4b4332e6-c822-11db-beb400a0c9f21fc7]-00080000-00000000
2020-06-29 18:55:00.302    [DEBUG][4]    dw1=00080000 vs 00080000
2020-06-29 18:55:00.303    [DEBUG][4]    Got capture filter: 'Hauppauge WinTV 885 TS Capture'
2020-06-29 18:55:00.303    [INFO][4]    medium:     [4b4332e6-c822-11db-beb400a0c9f21fc7]-00080000-00000000
2020-06-29 18:55:00.303    [DEBUG][4]    Added capture filter
2020-06-29 18:55:00.305    [DEBUG][4]    Connected Tuner to Capture
2020-06-29 18:55:00.339    [DEBUG][4]    Graph filter list:
2020-06-29 18:55:00.340    [DEBUG][4]     - MPEG-2 Sections and Tables
2020-06-29 18:55:00.340    [DEBUG][4]     - BDA MPEG2 Transport Information Filter
2020-06-29 18:55:00.340    [DEBUG][4]     - MPEG-2 Demultiplexer
2020-06-29 18:55:00.340    [DEBUG][4]     - NPVR TS Mon
2020-06-29 18:55:00.340    [DEBUG][4]     - Capture
2020-06-29 18:55:00.340    [DEBUG][4]     - Tuner
2020-06-29 18:55:00.340    [DEBUG][4]     - Network Provider
2020-06-29 18:55:00.340    [DEBUG][4]    Starting graph...
2020-06-29 18:55:00.461    [DEBUG][4]    Calling LockChannel()
2020-06-29 18:55:00.461    [DEBUG][4]    locked=0, present=0, strength=40000, quality=0   (took 0ms to check)
2020-06-29 18:55:00.463    [DEBUG][4]    DigitalRecorderDVBT::Tune@1
2020-06-29 18:55:00.463    [DEBUG][4]    DigitalRecorderDVBT::Tune@2
2020-06-29 18:55:00.463    [DEBUG][4]    DigitalRecorderDVBT::Tune@3
2020-06-29 18:55:00.463    [DEBUG][4]    DigitalRecorderDVBT::Tune@4
2020-06-29 18:55:00.473    [DEBUG][4]    DigitalRecorderDVBT::Tune@5
2020-06-29 18:55:01.436    [DEBUG][4]    DigitalRecorderDVBT::Tune@post
2020-06-29 18:55:01.436    [DEBUG][4]    KSPROPERTY_HCW_DVB_T2_PLP_INDEX Supported
2020-06-29 18:55:01.550    [DEBUG][4]    MPLP count: 0
2020-06-29 18:55:01.612    [DEBUG][4]    MPLP count: 0
2020-06-29 18:55:01.615    [DEBUG][4]    Calling LockChannel()
2020-06-29 18:55:02.542    [DEBUG][4]    locked=1, present=1, strength=-10000, quality=100   (took 922ms to check)
2020-06-29 18:55:02.542    [DEBUG][4]    StartStream()@exit handle=1
2020-06-29 18:55:02.542    [DEBUG][4]    StartStream succeded. Handle: 1
2020-06-29 19:54:48.073    [INFO][5]    Got GET request: /shutdown

I have tried forcing it to quit - starting a recording, locking the PC and signing back in to see if I could halt the recording in its tracks, but without any success and examining the logs files, no shutodwn line, just a more usual 'GET request: /stream/stop?handle=3' line at the end of the recording amongst all the others about stopping graphs and filters. So it does not seem to do it every time, and has done many recording perfectly. It's just an occasional thing.

I could of course do some workarounds - I could return to version 4, I could stop my screen locking, I could studiously avoid unlocking my machines at times likely to impinge on a recording, but none of those are things I really want to do.

So, has anyone got any suggestions, any idea what causes this 'GET request: /shutdown' to be emitted?

Many thanks.

PS: I guess you may want to know, I'm running Windows 10 1909, NextPVR 5.0.6 (200614), using a Hauppauge WinTV-QuadHD, with a Ryzen 7 2700 and 32Gb of RAM.

[mvallevand]

We need all the zipped logs, I suspect the

Got GET request: /shutdown

Is the culprit coming from an earlier EPG update which is possibly fixed with this https://forums.nextpvr.com/showthread.ph...#pid543084

Martin

[mshuttle]

I will give that dll a go. Excuse, my starting such a similar thread, I had drilled straight down into the Windows sub-forum as it seemed likely to be a Windows lock screen issue and hadn't seen the referenced thread.

I just noticed that one of the logs I was looking at had a 'GET request: /shutdown' appended just as I logged back into my machine a few moments ago. NPVR wan't recording at the time, so it's not related to recording necessarily, it's just fatal to the recording if it's active at the time.

I attach a zip of my logs folder if that's of help. 
  logs.zip (Size: 1.91 MB / Downloads: 2)

[mvallevand]

Did you get the zip files from the web server? This look like you zipped the folder which is not good for sending locked files.

Martin

[mshuttle]

Ah, nope, that was from the logs folder. I hadn't realised there was a significant difference and I was already in the logs folder looking at the logs.

Here's the logs from the server...


  logs-20200630-0814.zip (Size: 1.78 MB / Downloads: 2)

[Graham]

Ah, nope, that was from the logs folder. I hadn't realised there was a significant difference and I was already in the logs folder looking at the logs.

NextPVR V5 does not write logs to disk line by line but writes a whole bunch of lines at intervals.  Looking at logs in the folder will not show the latest messages in a log.

Pressing the zip button in Settings forces a flush of any outstanding messages to disk.  You can press the zip button and cancel the save of the zip file to force a flush.

[mvallevand]

Are you forcing sleep or are your letting the PC sleep on it's own? There is a difference in behaviour

For the logs also note that all open logs won't be included if you just zip a folder so we miss all information for the existing session.

Martin

[mshuttle]

I let the PC fall asleep of its own accord. I have a 5 minute timeout to locking the screen and 15 min to falling asleep. Of course, while it was recording 'Five-0 it had awoken but was locked, then I unlocked it and boom!, recording death.

[sub]

I let the PC fall asleep of its own accord. I have a 5 minute timeout to locking the screen and 15 min to falling asleep. Of course, while it was recording 'Five-0 it had awoken but was locked, then I unlocked it and boom!, recording death.

Does this updated NShared.dll fix it for you?

[mshuttle]

I installed the new dll about 00:30 on 1st July. The machine has done several recordings and been to sleep and woken several times over the course of the day, also a (deliberate) reboot around 22:30. There is no sign of early recording termination or the shutdown request so far. I'll keep checking, but I'll hazard a guess that the new dll has done the trick. Latest logs attached.

Many thanks

Mark


  logs-20200702-0026.zip (Size: 476.59 KB / Downloads: 0)