Recordings Failing with "No Errors but no Data Delivered" message

[BrettB]

In the last couple of weeks, I've had several recordings from my HDHR primes fail with the "No Errors but no Data Delivered" message. In the last 2 days these recordings failed:

1. 4/18/17 8:59pm NCIS: New Orleans (tuner moved at record time)
   
2. 4/20/17 7:59pm Scandal (not moved)
   
3. 4/20/17 8:00pm The Amazing Race (moved)
   

I've looked in the logs (see attached) and can't really see any reason. Different channels, different tuners, some moved/some not, etc.

I also included the system logs from the HDHRs, and they don't show any sort of errors--everything looks the same there for recordings that work fine and those that failed.

Do you see anything, sub? Any ideas about anything else that I should check?


I'm out of quota, so can't upload my logs here. You can download them from:
https://bowmantech-my.sharepoint.com/per...N7EICc9yMQ

[mvallevand]

I didn't check them all but that first sample had two (of the six concurrent) recordings for your "record all new S01E01" rule which might be causing some tuner scheduling logic issues.

Martin

[BrettB]

I didn't check them all but that first sample had two (of the six concurrent) recordings for your "record all new S01E01" rule which might be causing some tuner scheduling logic issues.

Interesting thought, Martin. The 2nd 2 examples were at the same time. And when the failures happen, there are (probably always) several concurrent recordings going on. (But it definitely doesn't have every time that there are 4+ concurrent recordings.) I have also noted more shows getting picked up by the S1E1 rule recently. (I'm guessing that more of the "lesser" channels are providing that info to the guide service now.) But I hadn't noticed any correlations between the failed recordings and S1E1 recordings. I'll look for that in the ones that I've still got listed and any future occurrences.

[BrettB]

Interesting thought, Martin. ... But I hadn't noticed any correlations between the failed recordings and S1E1 recordings. I'll look for that in the ones that I've still got listed and any future occurrences.

Well, last night there were 3 back-to-back recordings (none of which were S1E1 recordings) on one channel and all 3 failed. There were 2 Dr. Jeff and 1 Dr. Jeff Extra Dose starting at 2017-04-22 17:59:00.137 in NRecord.log.1.

Logs can be found here https://bowmantech-my.sharepoint.com/per...A-oEwA1ppc

[sub]

Well, last night there were 3 back-to-back recordings (none of which were S1E1 recordings) on one channel and all 3 failed. There were 2 Dr. Jeff and 1 Dr. Jeff Extra Dose starting at 2017-04-22 17:59:00.137 in NRecord.log.1.

I can't see any obvious sign of problems around those recordings. If this is happening regularly, you might need to try catch it when this is happening, and open the HDHR Config app, and see if it thinks there is a signal lock, and it's network bitrate etc.

Do other recordings on that specific channel still work? ie, they haven't changed the channel number or other aspect about that channel that would invalidate NextPVR's stored tuning information for that channel?

You don't have any other software set up that could have been using that tuner at the time it was required?

[BrettB]

I can't see any obvious sign of problems around those recordings. If this is happening regularly, you might need to try catch it when this is happening, and open the HDHR Config app, and see if it thinks there is a signal lock, and it's network bitrate etc.

I've had it happen on a rare occassion in the past, but the last 3-4 weeks, I've had at least 10 recordings fail like this. So, it is definitely happening more frequently now. Of course, the trick is catching it when it is happening. I may put something in my ParallelProcessing.bat file to monitor for file growth and alert me immediately if that isn't happening.

If the HDHR is indeed sending a stream over the net to NextPVR, is there anything that I could check, etc. on the NextPVR side to try to help determine why it isn't receiving it or writing it to the .ts file?

Do other recordings on that specific channel still work? ie, they haven't changed the channel number or other aspect about that channel that would invalidate NextPVR's stored tuning information for that channel?

The recordings are on different channels. And a recording on a channel will fail, then another recording on the same channel an hour later works just fine. So I'm quite sure that it isn't a tuning, etc. problem.

You don't have any other software set up that could have been using that tuner at the time it was required?

There shouldn't be any other software using the tuner. And, in fact, in all the cases where I looked at the System Log on the HDHR (logs included in the first post log.zip file), the HDHR is showing that it tuned the channel and is streaming to the correct IP address and port specified by the NextPVR log.

[BrettB]

I can't see any obvious sign of problems around those recordings. If this is happening regularly, you might need to try catch it when this is happening, and open the HDHR Config app, and see if it thinks there is a signal lock, and it's network bitrate etc.

OK. It's happening right now with an episode of Riverdale. Here's the HDHR Tuner Status Screen
[ATTACHMENT NOT FOUND]

I did a Wireshark network capture, and verified the HDHR is sending a stream to UDP port 36314. I can make that available for you if it would help.

I used Process Hacker 2 to look at the NRecord process, but I can't figure out how to determine which thread should be listening on port 36314 to see what that thread is doing.

[BrettB]

OK. It's happening right now with an episode of Riverdale.

Then at 20:59 it happened again with 2 recordings: The Amazing Race & Inside the FBI New York. In both cases, I canceled the recording and then immediately rescheduled it to record and that recording worked just fine.

[sub]

If you stop the NextPVR recording service, and run resmon.exe, click 'Network' and expand Listening Ports, you don't see anything else listening on port 36319?

[BrettB]

If you stop the NextPVR recording service, and run resmon.exe, click 'Network' and expand Listening Ports, you don't see anything else listening on port 36319?

OK, I'm not sure why you specified port 36319. But here's what I found...

First, I checked in ResMon for listening port before doing anything else. Then I exited the Kodi webclient running on my RPi in preparation from stopping the NextPVR service. Here is what I then saw:
[ATTACHMENT NOT FOUND]
Notice that nothing was listening on port 36319, but NRecord had been listening on port 36314 (which was the port from the original Riverdale failed recording), 36315 (the port from the original failed Amazing Race recording), and 36316 (the port from the original failed Inside the FBI recording--I also not from the logs that this recording couldn't honor pre-padding because there wasn't an available tuner). When I first looked with ResMon (before I exited the webclient), the listening on ports 36314, 36315, and 36316 was still active (i.e. they were solid black)--unfortunately, I didn't capture that view. Then when I exited the webclient was when they turned grey (i.e. they had just closed).

A bit later, but still before I stopped the NPVR recording service, this is what I saw:
[ATTACHMENT NOT FOUND]
Then I stopped the service, and the remaining listening ports closed/greyed:
[ATTACHMENT NOT FOUND]
Then a bit later, after the stop and before the restart:
[ATTACHMENT NOT FOUND]

So, it seems that somehow there is a link between the webclient server thread and the failed recording threads... I guess the next time that it happens, I can try just exiting the webclient and see if the failing recordings then begin saving to the .ts file. Anything else that I can try/check?