0 Length Recordings....Again....

[sub]

About the original recording problem, or this network socket thing?

For the original problem, I'd need to see the nrecord.log and ndigitalhost.log showing the failed recording.

I'm not sure what'd be causing the socket thing, unless nrecord.exe is already running, or something firewall related is holding the port open.

[UncleJohnsBand]

About the original recording problem, or this network socket thing?

For the original problem, I'd need to see the nrecord.log and ndigitalhost.log showing the failed recording.

I'm not sure what'd be causing the socket thing, unless nrecord.exe is already running, or something firewall related is holding the port open.

Recording issue.... I not concerned with the socket thing at this point.

Logs from tonight's failure...

[sub]

Hmm, there is nothing obvious in the logs other than this message you've already pointed out:

2013-01-09 20:00:08.110 [DEBUG][4] Unexpected error on ATSC put_TunerRequest: 0x8000FFFF

Its not clear to me why the tuning might be failing though.

It might be worth setting <TuneTwiceOnDigitalChannels> to true in config.xml. It may not fix it, but it'll be interesting to see if both tuning requests generate this same error.

[UncleJohnsBand]

Hmm, there is nothing obvious in the logs other than this message you've already pointed out:

2013-01-09 20:00:08.110 [DEBUG][4] Unexpected error on ATSC put_TunerRequest: 0x8000FFFF

Its not clear to me why the tuning might be failing though.

It might be worth setting <TuneTwiceOnDigitalChannels> to true in config.xml. It may not fix it, but it'll be interesting to see if both tuning requests generate this same error.

Thanks... I'll give it a go and report back.

[whurlston]

UJB, what do you have specified as the target app in the HDHR setup? If you have it set to NextPVR, you might try setting it to "Other: ATSC/QAM" or vice versa.

[UncleJohnsBand]

Hmm, there is nothing obvious in the logs other than this message you've already pointed out:

2013-01-09 20:00:08.110 [DEBUG][4] Unexpected error on ATSC put_TunerRequest: 0x8000FFFF

Its not clear to me why the tuning might be failing though.

It might be worth setting <TuneTwiceOnDigitalChannels> to true in config.xml. It may not fix it, but it'll be interesting to see if both tuning requests generate this same error.

Thanks... I'll give it a go and report back.

Gave it a go..... fail. No error....message indicating tuning twice but still zero length file.... but whurlston may have inadvertently pointed me to the issue....

UJB, what do you have specified as the target app in the HDHR setup? If you have it set to NextPVR, you might try setting it to "Other: ATSC/QAM" or vice versa.

When I went into HDHR setup.... I got a message upgrading firmware.... seemed odd since I had done that a while ago.... so exited went back in and got the same message. So I went into the HDHR tunner gui to check firmware on the two units..... one tuner responded 20130104 beta firmware.... the other tuner unable to display page.

Rebooted both HDHR tuners, started recording service (without tune twice) and recording was working......HDHR Config shows tuner that was responding now with same firmware.....

At this point I will have to chalk it up to a firmware upgrade on the HDHR a week or so ago that must have put one of the tuners out of whack.

One recording doesn't make it fixed but it is promising.

whurlston.... I am set at NPVR.... should I switch that as well?

[sub]

Ok - fingers crossed it stays that way.

[whurlston]

whurlston.... I am set at NPVR.... should I switch that as well?

Not if it's currently working. Mine is set to NextPVR but some people have reported it not working and had to use Other.

I'm guessing your problem was due to the bad firmware load so let's go with that assumption until it proves otherwise.

[UncleJohnsBand]

Not if it's currently working. Mine is set to NextPVR but some people have reported it not working and had to use Other.

I'm guessing your problem was due to the bad firmware load so let's go with that assumption until it proves otherwise.

Ok... thanks.


I had two more 0 length recordings (both started after the one good one that was running)...... but I noticed the npvr tray icon wasn't red and it should have been. Checked and I had a socket error again...... and using sysinternal's tcpview I could see that the ports were held open by a my new w8 laptop..... which I think is related to the NPVR gadget I had running. W8 does not provide a gadget host any longer but there is one out there for w8 and I am wondering if it is doing something with causing the connection from the laptop to the webadmin to lock the 8866 port..... just not sure.

So I have now removed the gadget and will wait to see what happens in regards to the socket.

[UncleJohnsBand]

I was still seeing socket blocks so I started watching as I start and stop the recording service and was seeing the nrecord process occasionally becoming orphaned somehow. Using process explorer I discovered that the utilidev web server was running on my server..... from when I ran the install of the web console but then uninstalled since I did see instability following the install of it..... I thought it was gone but there were two processes for it still running. Disabled services and manually removed the directory.

starting and stopping the service has not caused a hang in nrecord since I rebooted following this. I started a couple of recordings without issue and have a few scheduled to start in about 20 minutes.

I'll report back on what happens...... my thought is that if the web console was still loading in utilidev and somehow got its hooks in npvr that it could cause an unclean shutdown and create the orphan processes with open sockets.