Colussus captures missing a lot of data

[sub]

You could try creating a c:\temp directory, and setting the following registry value, then reproduce the problem. This will create a c:\temp\dump.ts, containing an untouched dump of the data delivered from the device, before NextPVR does any processing of the data. The contents of this file will give you an indication if the device is delivering broken data, or if NextPVR is somehow breaking on it's way to making recordings.

On 64bit Windows: HKEY_LOCAL_MACHINE\Software\Wow6432Node\NPVR\ DumpFileWriter=1 (DWORD)
On 32bit Windows: HKEY_LOCAL_MACHINE\Software\NPVR\ DumpFileWriter=1 (DWORD)

[theason]

If you don't want to use fixed bitrate you should increase the bitrate for SD recording in config.xml.

I'd be completely open to trying a fixed bit rate. Would you recommend something that I should use for my settings in the config.xml? I'm using the default config that comes with the install right now.

[theason]

You could try creating a c:\temp directory, and setting the following registry value,)

Will I run into any issues if both Colossus cards start capturing at the same time? The C drive is a PCIe SSD card, so it should handle the raw dump I'd think.

[mvallevand]

For fixed bit rate I was meaning changing the STB to output fixed. I use 720p for the most compatibility. For config.xml just modify the SD res. to match either 720p or 1080i.

Martin

[sub]

Will I run into any issues if both Colossus cards start capturing at the same time? The C drive is a PCIe SSD card, so it should handle the raw dump I'd think.

Yes, that would cause problems, both devices would be writing to the same dump.ts, leading to a corrupt file. You'll need to reproduce the problem with a single device.

[theason]

Alright, I just switched all of the classes in the config file to be CBR; and increased the Bitrates for SD since almost everything is being recognized as SD, and the last hour of recordings are coming through with really appropriate file sizes.

<WaitLongerBeforeRecordingCapture>true</WaitLongerBeforeRecordingCapture>
<Mode720p>
<Bitrate>9000000</Bitrate>
<BitratePeak>13500000</BitratePeak>
<BitrateMode>CBR</BitrateMode>
</Mode720p>
<Mode1080i>
<Bitrate>9000000</Bitrate>
<BitratePeak>13500000</BitratePeak>
<BitrateMode>CBR</BitrateMode>
</Mode1080i>
<ModeSD>
<Bitrate>9000000</Bitrate>
<BitratePeak>13500000</BitratePeak>
<BitrateMode>CBR</BitrateMode>
</ModeSD>
</HDPVR>

[theason]

So this seems good...

2015-04-30 21:00:48.948 [INFO][9] About to start graph
2015-04-30 21:00:48.962 [DEBUG][9] Device reports resolution(2): 0x0 (fps:0) (aspect:0) (progressive:0) (videoIdCode:0)
2015-04-30 21:00:49.072 [DEBUG][9] device minimum bitrate: 100000
2015-04-30 21:00:49.072 [DEBUG][9] device maximum bitrate: 20000000
2015-04-30 21:00:49.072 [DEBUG][9] device bitrate step size: 100000
2015-04-30 21:00:49.082 [DEBUG][9] device reports current bitrate as: 9000000
2015-04-30 21:00:49.092 [DEBUG][9] device reports current peak bitrate as: 9000000
2015-04-30 21:00:49.092 [DEBUG][9] About to set BITRATE MODE
2015-04-30 21:00:49.102 [DEBUG][9] requesting constant encoding
[COLOR="#FF0000"]2015-04-30 21:00:49.112 [DEBUG][9] trying to request bitrate: 9000000
2015-04-30 21:00:49.122 [DEBUG][9] device confirms bitrate as: 9000000[/COLOR]
2015-04-30 21:00:49.134 [DEBUG][9] Device started
2015-04-30 21:00:49.154 [DEBUG][9] Device reports resolution(3): 1920x1080 (fps:30) (aspect:2) (progressive:0) (videoIdCode:5)
2015-04-30 21:00:49.154 [DEBUG][9] Delaying start of HDPVR recording capture
2015-04-30 21:00:52.306 [DEBUG][11] Client Listener starting on port 7969
2015-04-30 21:00:55.655 [DEBUG][9] About to switch HDPVR/Colossus to target:
D:\RECORDINGS\Octonauts\Octonauts_20150430_21002130-0.ts
2015-04-30 21:00:55.656 [INFO][9] HDPVRRecorder.StartStream() allocated handle: 0x1
2015-04-30 21:00:55.656 [DEBUG][9] Temp at 4/30/2015 9:01:05 PM
2015-04-30 21:00:55.656 [DEBUG][9] Started recording (2720:1:\RECORDINGS\Octonauts\Octonauts_20150430_21002130-0.ts)

[theason]

Well, I think I'm back to square one. Couple of things I can note:

1) The recording you see here at top of the list had only 300 frames written for 30 minutes
2) According to the logs, the previous huge recording you see was written on the same card as the failed one (Colossus #0).

[sub]

Did you try capturing that dump.ts?

[theason]

Last night I finally found a period where there was just one recording at a time happening, and turned on the flag in the registry. The dump file produced was right about the same size and frame content as the regular one written.

I have made a couple of other key findings:

- It doesn't matter which of the two cards does the capture. Both cards will produce a file with about 1/6th of the average frames.
- It DOES matter if you restart the nRecord service.

I had two recordings going this AM, one on each card. Both had been going for a few minutes and it was clear they were way under the normal sizes. I bounced the nRecord service and the new files being written now, (same recordings, same channels, same cards each doing their job) are already larger than the ones that had started before.

I suspect that the system will continue writing good recordings now for a period and eventually degrade again over about 24 hours.

I wonder if just bouncing nRecord with a scheduled task every 6 hours would start giving me better results.