NextPVR Forums

Recordings occasionally fail in the middle. The SageDCT log file contains numerous GetSize has not changed errors. NPVR never recovers after this and I have to recycle SageDCT & NPVR server. Every attempt to view live tv or record fails until this is done. Besides this being a bug, are there any suggestions about how I might detect and recover from this condition? I'm thinking of a watchdog script with the power to restart the services. It will have to run with admin privileges in order to restart services. Has anyone tried this? The script will have to wait until x seconds/minutes of these messages occur before it takes action, but it seems that the size check is performed every 30 seconds, so perhaps one message is enough to restart.

2012/12/17 11:47:07.22 : RTP Sequence Number: 51585 Timestamp: 9780823 Size: 7896
2012/12/17 11:47:07.24 : RTP Sequence Number: 51586 Timestamp: 9780823 Size: 7896
2012/12/17 11:47:07.24 : RTP Sequence Number: 51587 Timestamp: 9780823 Size: 7896
2012/12/17 11:47:10.02 : After Accept: 6980
2012/12/17 11:47:10.02 : 6980 Bytes Received: 6
2012/12/17 11:47:10.02 : ProcessMessage 6980: NOOP
2012/12/17 11:47:10.02 : SageDCTTuner 6980 Send: OK
2012/12/17 11:47:10.02 : Before Accept: 6980
2012/12/17 11:47:15.18 : After Accept: 6980
2012/12/17 11:47:15.18 : 6980 Bytes Received: 91
2012/12/17 11:47:15.18 : ProcessMessage 6980: GET_FILE_SIZE L:\NextPVR\Video\The Singing Marine\The Singing Marine_20121217_11151315.ts
2012/12/17 11:47:15.18 : GET_FILE_SIZE for L:\NextPVR\Video\The Singing Marine\The Singing Marine_20121217_11151315.ts
2012/12/17 11:47:15.18 : SageDCTTuner 6980 Send: 3162288968
2012/12/17 11:47:15.18 : Before Accept: 6980
2012/12/17 11:47:15.85 : SageDCT.exe PrivateMemorySize: 41807872 WorkingSet: 31584256 PeakWorkingSet: 32567296 TotalProcessorTime: 01:17:44.9915036
2012/12/17 11:47:20.30 : After Accept: 6980
2012/12/17 11:47:20.30 : 6980 Bytes Received: 6
2012/12/17 11:47:20.30 : ProcessMessage 6980: NOOP
2012/12/17 11:47:20.30 : SageDCTTuner 6980 Send: OK
2012/12/17 11:47:20.30 : Before Accept: 6980
2012/12/17 11:47:25.48 : After Accept: 6980
2012/12/17 11:47:25.48 : 6980 Bytes Received: 91
2012/12/17 11:47:25.48 : ProcessMessage 6980: GET_FILE_SIZE L:\NextPVR\Video\The Singing Marine\The Singing Marine_20121217_11151315.ts
2012/12/17 11:47:25.48 : GET_FILE_SIZE for L:\NextPVR\Video\The Singing Marine\The Singing Marine_20121217_11151315.ts
2012/12/17 11:47:25.48 : GetSize has not changed: 3162288968 - 12/17/2012 11:47:15 AM
2012/12/17 11:47:25.48 : WARN GetSize has not changed: 3162288968 - 12/17/2012 11:47:15 AM
2012/12/17 11:47:25.48 : SageDCTTuner 6980 Send: 3162288968
2012/12/17 11:47:25.48 : Before Accept: 6980
2012/12/17 11:47:30.54 : After Accept: 6980
2012/12/17 11:47:30.54 : 6980 Bytes Received: 6
2012/12/17 11:47:30.54 : ProcessMessage 6980: NOOP
2012/12/17 11:47:30.54 : SageDCTTuner 6980 Send: OK
2012/12/17 11:47:30.54 : Before Accept: 6980
2012/12/17 11:47:35.66 : After Accept: 6980
2012/12/17 11:47:35.66 : 6980 Bytes Received: 91

What does the NRecord.log look like?

Marti

I have this same problem. In the SageTV world, it would try to recover from the "halt" and continue to record (but using a new file that would have a -1 or a -2 appended to the end of the file name). 1) Can NPVR support something like that, and 2) what can I do to help debug as this is a key piece to have working in NPVR before I fully jump from SageTV?

SageTV is much more sophisticated dealing with tuner errors, currently NextPVR only restarts incomplete recordings on restart of the recording service.

Martin

mvallevand Wrote:SageTV is much more sophisticated dealing with tuner errors, currently NextPVR only restarts incomplete recordings on restart of the recording service.

Martin

Understood. Is there a way to add this to a list of future improvements? I'm sure it's a big list, but it would be a great feature to improve the overall stability/usability.

I have a request in to sub to improve handling of an NDigitalHost lockup; this wouldn't directly help with this, but hopefully such refinements could be applied to other tuner scenarios as well.

When I read LehighBri's comment about the halt issue on the SageTV forum, I considering spawning a batch file which could stop and start the recording service, and partially resolve this issue. I decided against it because the recording services is also the core of the persistent sockets that all the clients open and only the XBMC client seems to reconnect reasonably.

Martin