Extended Recording Stopped Early

[mvallevand]

There are registry setting yes but it depends on what you are looking to log.

General verbose logging (which doesn't give much information for standard broadcast recording issues) can be temporary enable by ctrl-clicking the log in the web browser. There is an environment setting to make it permanent if you search the forum.

Martin

[jcole998]

Thanks, Martin, I'll give it a try. I was hoping the verbose logging would show disk activity during a recording.

In the meantime, I'm trying different hard drives and a different server to see if that makes a difference.

JohnC

[sub]

In the meantime, I'm trying different hard drives and a different server to see if that makes a difference.

I was only really checking this angle in case you were using a filesystem that had a limit of 2GB files or similar.

[jcole998]

I have been doing extensive analysis on trying to determine why recordings are ending early. I am using Wireshark to help.

I used Wireshark to log all packets during a one-hour session with three HD shows being recorded simultaneously. This resulted in an aggregate output rate of about 37Mbps.

I used V5 for this test that commenced at 11:59:00am
- The recordings ended approximately 11 minutes into the session.
- The Hauppauge DCR-3250 device's three tuner lights had been blinking for about 20 seconds before all of them turned off.
- No packets were received after the tuner lights started blinking.
- During that blinking time I was able to check the status of the tuners using the Hauppauge web status. All three tuners were still locked by the server but output streaming rate for each one was zero.

Wireshark showed a total breakdown of flow control between the server and the Hauppauge device. It seemed that the Hauppauge simply stopped sending after TCP flow control was disrupted for too long. But that's a guess.

I tried the same test that commenced at 10:59:00am on the same machine but this time using V4. No issues of any kind. The recordings completed perfectly.

Now...would it be possible to get a version of V5 that uses UDP instead of TCP I can test with? Or is there some setting I can adjust to improve TCP flow control?

Thanks.

JohnC

[mvallevand]

Was the V4 service shutdown before you started your V5 test? There is a missing v4 log so this is not clear.

Martin

[jcole998]

Yes, V4 service was not running with the V5 test. The two services are on different ports: V4-8866, V5-8867. Both are started manually and I'm real careful to be sure they're both stopped before starting the one I need.

[mvallevand]

It's not the ports it is how they control the HDHR, since it is down it isn't an issue. Does it work ok with just two running? It could be a USB throughput issue.

Martin

[jcole998]

The device being used is a Hauppauge DCR-3250 cable card triple tuner that uses ethernet connections, not USB. My LAN equipment is all gigabit capable and consists of the Verizon modem/router and gigabit switches.

Recording from only two tuners simultaneously only delays the problem a little longer but still results in at least one of the recordings ending early. 

Do you think that some recent Microsoft update changed the behavior of TCP somehow? I've seen updates for .Net Framework versions 3.5 and 4.8 as recently as this February.

JohnC

[mvallevand]

Ok sorry I thought it was the USB model. NextPVR server V5 use .netcore not .net framework. I don't think it is a Microsoft issue but it does seem network related which seems to be confirmed by Wireshark. Maybe try running this outside of NextPVR

Code:

start curl "http://ip:5004/tuner0/v###?duration=3600" -o ###.ts
start curl "http://ip:5004/tuner1/v###?duration=3600" -o ###.ts
start curl "http://ip:5004/tuner2/v###?duration=3600" -o ###.ts

to see if it can record 3one hour shows outside NextPVR with no error

Martin

[jcole998]

Excellent suggestion! I did not know one could do that. Thank you.