Failed to lock a signal

[sub]

Can you see if this patch helps?

[roy]

Yes, that helped. Both recordings and tuners worked properly. Logs attached.

I'll do some more testing with other scenarios later today to see how that looks.

Thanks

[roy]

Now back to original problem of failed back to back recordings. Logs attached. I'll try to get a more concise log now.

[sub]

More logging.

[roy]

I did several manual recording scenarios without fail. Dual back to back recordings is how I can reproduce it. These logs show this. Both recordings at 16:30 and 17:00 were good. Both recordings at 17:30 and 18:00 were 0 byte.

[sub]

The cause isnt obvious in the logs, but give this a go. Hopefully it'll help. If it doesnt, I suspect I'll need to give you an updated NPVRNetPushSource.ax with more logging (and removing some of the messages that made that netpush.txt file so huge).

[ttfitz]

The cause isnt obvious in the logs, but give this a go. Hopefully it'll help. If it doesnt, I suspect I'll need to give you an updated NPVRNetPushSource.ax with more logging (and removing some of the messages that made that netpush.txt file so huge).

I've been following along with Roy, but haven't had a chance to try earlier fixes. I had a chance with this one, and tried it out.

I setup manual recordings - iontest and abctest - for a 5 minute record at 11:15pm, and a second (iontest2 and abctest2) at 11:20, all of them with 1 minute pre- and post-padding. When I saw that the second pair appeared to be recording correctly, I then setup a third pair (iontest3 and abctest3, strangely enough) to start at 11:25. This last pair ended up with 0 bytes captured.

I don't know if this might have anything at all to do with this, but I did notice something tonight. When I look at the DCR-2650 status screens, when I have 0 or 1 tuner at work, the entry "Card OOB lock" shows "success." But when both tuners are recording, it shows "weak". The signal screens for each tuner still are strong (91 and 92% signal strength).

I've attached the log from the test above.

[roy]

Still the same, per the log attached. Might it have something to do with padding? I think I see in the log that the next recording starts before the previous one ends.

So then I tried a set of recordings without padding, but the third on each tuner is still 0 byte. Log attached.

Without padding I noticed the tuner lights blink off between the good recordings, but not blink for the fails, I think. :confused:

Thanks again, and good night.

[sub]

With a c:\temp, and this patch, and HKEY_LOCAL_MACHINE\Software\NPVR\LogNetPush=2, reproduce the problem (with as-few-as-possible short recordings), then zip and attach the nrecord.log and c:\temp\netpush-xxxx.txt

We will get there eventually. At this stage I'm just trying to understand what is happening, so more logging.

[roy]

Logs attached show good recordings 1a, 2a, 1b and 2b - then 0 byte recordings 1c and 2c both starting at 18:55. The netpush.txt file starts getting large at that point with the failed lines, and the system bogs down due to this logging, I think.

Code:

18:55:02.481    [4344]    About to bind port 5005
18:55:02.481    [4344]    StartReceiver. Bind Failed
18:55:02.481    [4344]    Successfully set socket buffer size
18:55:02.481    [4344]    StartReceiver. recvfrom failed rc=00002726
18:55:02.481    [4344]    closing socket

I had to trim it down.

Another thing I've noticed before, and probably is not related, is that recordings with post padding that stop recording at the actual end time (without padding, because the tuner is lost to another recording) still show as recording in the recordings screen until the padding time has passed.