Netpush file growing wildly

[ttfitz]

I am posting this in support because I'm passing on some of the problem stuff, but it is mostly a request for a change.

At some point along the line, I put some sort of option into my setup which creates a "netpush" file in C:\temp - don't remember how or why, but maybe I'll dig into it more if I decide to stop doing it. Anyway, I guess it is some sort of debug thing, and it's usually fine, but occasionally something goes wrong and the file grows like crazy. As in, it becomes gigabytes in size and fills up my C: drive. When this happens, there is usually a recording that doesn't get started (0 bytes in size), so I have basically left this in place as it acts as a "canary in the mine" sort of thing - when I get the "You are running out of space on C:" message, I know that something isn't getting recorded properly.

Anyway, it would be nice if this file had some sort of size limit or such on it, and did like the other log files do - close one and start writing to another, so I can just delete the older ones that have the same info over and over again, rather than having to shut down the NPVR service while other stuff is recording.

As for the problem, in case someone wants to look at it, the latest occurrence was tonight, when attempting to record The Nightly Show at 23:30. Attached is Nrecord log, and the netpush file had a bunch of this:

23:30:01.257 [5944] Constructor
23:30:01.257 [13936] StartReceiver
23:30:01.258 [12324] FillBuffer GetSize()=1880
23:30:01.317 [13936] About to bind port 36314
23:30:01.317 [13936] StartReceiver. Bind Failed
23:30:01.317 [13936] Successfully set socket buffer size
23:30:01.317 [13936] StartReceiver. recvfrom failed rc=00002726
23:30:01.317 [13936] closing socket
23:30:01.317 [13936] About to bind port 36314
23:30:01.317 [13936] StartReceiver. Bind Failed
23:30:01.317 [13936] Successfully set socket buffer size
23:30:01.317 [13936] StartReceiver. recvfrom failed rc=00002726
23:30:01.317 [13936] closing socket
23:30:01.317 [13936] About to bind port 36314
23:30:01.317 [13936] StartReceiver. Bind Failed
23:30:01.317 [13936] Successfully set socket buffer size
23:30:01.317 [13936] StartReceiver. recvfrom failed rc=00002726
23:30:01.317 [13936] closing socket
23:30:01.317 [13936] About to bind port 36314
23:30:01.317 [13936] StartReceiver. Bind Failed
23:30:01.317 [13936] Successfully set socket buffer size
23:30:01.317 [13936] StartReceiver. recvfrom failed rc=00002726
23:30:01.317 [13936] closing socket
23:30:01.317 [13936] About to bind port 36314
23:30:01.317 [13936] StartReceiver. Bind Failed
23:30:01.317 [13936] Successfully set socket buffer size
23:30:01.317 [13936] StartReceiver. recvfrom failed rc=00002726
23:30:01.317 [13936] closing socket
23:30:01.317 [13936] About to bind port 36314
23:30:01.317 [13936] StartReceiver. Bind Failed
23:30:01.317 [13936] Successfully set socket buffer size
23:30:01.317 [13936] StartReceiver. recvfrom failed rc=00002726
23:30:01.317 [13936] closing socket
23:30:01.317 [13936] About to bind port 36314
23:30:01.317 [13936] StartReceiver. Bind Failed
23:30:01.317 [13936] Successfully set socket buffer size
23:30:01.317 [13936] StartReceiver. recvfrom failed rc=00002726
23:30:01.317 [13936] closing socket
23:30:01.317 [13936] About to bind port 36314
23:30:01.317 [13936] StartReceiver. Bind Failed
23:30:01.317 [13936] Successfully set socket buffer size
23:30:01.317 [13936] StartReceiver. recvfrom failed rc=00002726
23:30:01.317 [13936] closing socket

Repeating for 3 gigabytes or so.

Thanks.

[johnsonx42]

it's a debugging file that's only being created because you turned on a debug setting in the registry. find the setting and delete it (it's surely in HKLM/Software/NPVR (or HKLM/Software/WoW6432Node/NPVR). there won't be any size management or log rolling for this sort of dump file.

[ttfitz]

it's a debugging file that's only being created because you turned on a debug setting in the registry. find the setting and delete it (it's surely in HKLM/Software/NPVR (or HKLM/Software/WoW6432Node/NPVR). there won't be any size management or log rolling for this sort of dump file.

Ah, that's too bad, I liked having the alert when something wasn't going right. It IS interesting, though, I went looking for the setting in the registry, and found it has a value of 0, NOT 1, but the file is still being created.

Are there any thoughts on the underlying problem, the program that didn't get recorded and produced all the data in the debugging file?

[mvallevand]

The probably have text 0 instead of an integer. That error code doesn't look good but it could mean you need to reboot because Windows is corrupt maybe a driver error explaining the 0 byte files.

Martin

[ttfitz]

The probably have text 0 instead of an integer. That error code doesn't look good but it could mean you need to reboot because Windows is corrupt maybe a driver error explaining the 0 byte files.

Martin

The registry setting is a DWORD, as instructed, so I don't think that explains the 0 vs. 1 thing.

I probably should reboot more often, I'll look into that.

[johnsonx42]

Ah, that's too bad, I liked having the alert when something wasn't going right.

I guess I didn't follow where having an errant debug log fill your hard drive could be a good thing... that can make a real mess of things; in the past there was a bug where config.xml would get destroyed if the c: drive ran out of space, I think NDigitalHost can lock up if space runs out, and I suspect you can still end up with database damage.

[sub]

The registry setting is a DWORD, as instructed, so I don't think that explains the 0 vs. 1 thing.

I probably should reboot more often, I'll look into that.

You definitely shouldn't getting a file if it is set to 0. You don't need to reboot, but you will need to at least restart the recording service.

[ttfitz]

I guess I didn't follow where having an errant debug log fill your hard drive could be a good thing... that can make a real mess of things; in the past there was a bug where config.xml would get destroyed if the c: drive ran out of space, I think NDigitalHost can lock up if space runs out, and I suspect you can still end up with database damage.

Well, yeah, that's why I wanted a way to delete parts so things didn't completely fill up when an error occurred.

[ttfitz]

You definitely shouldn't getting a file if it is set to 0. You don't need to reboot, but you will need to at least restart the recording service.

It's been set at zero for many, many reboots, I've had that setting in there a while. I put it in when there were problems like this before with other users of the DCR-2650 getting 0 byte recordings, and when those were fixed, I just changed the setting from 1 to 0 rather than delete the key (so I could turn it back on easier if needed). It was only when I recently had a recording getting no data while I was at the machine and saw the "You are running out of space on C:" message that I realized it was still being written.

[sub]

I definitely will not be doing anything to limit these log files that are only created with these special registry settings. They're only debug files, and user should not have enabled in normal use. They'll do more than just create big files - they will hurt performance. These need to be disabled unless looking into specific problems.