Defective TS files with displayed zero length

[mvallevand]

(I need to see if I can cut a chunk from the beginning of the recording to reduce the file size down from 1.8GB)

That is what sub's cutchunk utility on the wiki does. For this problem you don't need too big a sample.

Martin

[sub]

Sub, might this have any positive impact on UK Freeview H264 recordings?

This change would only effect an HDHomeRun Prime, or Hauppauge DCR, and in first 200k of a recording.

[gEd]

Sub, might this have any positive impact on UK Freeview H264 recordings?
I ask as I have been encountering a couple of corrupt TS files myself recently. TS Doctor says PMT invalid or missing and windows explorer hangs for several minutes if you navigate to the folder where the recording resides. I can open a separate thread if you don't think my issue is related to the OPs (I need to see if I can cut a chunk from the beginning of the recording to reduce the file size down from 1.8GB)

Just to close off my assertion that I was experiencing corrupt recordings. It transpires that the tuning on one of my channels was somehow wrong. Sorry about that.

[johnsta]

> Try this updated NPVRWriter.ax and let me know if it helps. It
> monitors the few PAT entries before they're written to disk, and
> throw away the data before them if the contents changes.

> Attached Files File Type: zip NPVRWriter.zip (48.0 KB, 10 views)

I've installed the following two ax files by replacing the
corresponding files in "c:\Program Files (x86)\NPVR", and
then killed and restarted NRecord.

02/01/2018 12:11 PM 153,088 NPVRTSReader4.ax
02/04/2018 09:33 AM 112,128 NPVRWriter.ax

I've been running the modified version of NPVR, and watching to see
what files are being created.

I haven't detected any differences in the number of defective files
being created.

The one difference I did notice is that what I've previously
called "partially defective" files now work a little differently.
These are files that display a 0:00 time duration in VLC, but can
still play in VLC and controlled using the progress bar.

The difference that I've noticed in these files, is that they used to
start playing almost immediately, but now only start playing after a
long delay that appears to be proportional to the size of the file. I
assume that VLC is now reading through and processing the file in some
way before starting to play.

I've now uploaded two test files:


** File #1 - Very short partially defective file

http://jxenakis.com/gdgraphics/The.Good....E14.She.ts

This is a small file that was created by canceling the recording after
about two minutes. It plays on VLC but shows 0:00 time duration. It
also plays in NPVR.


** File #2 - Totally defective - doesn't play in VLC or NPVR

http://jxenakis.com/gdgraphics/GMT_20180206_07000730.ts

This is a recording of an entire half-hour show. It does NOT play on
VLC, and it does NOT play on NPVR. It's totally defective.

Thanks,

John

[mvallevand]

The small plays fine in NextPVR for me with timeline, there is no extra PAT but there are some of the old a/v data packets which VLC might not like. The large file still shows one initial "bad" PAT at packet 11 so the NextPVR timeline is off.

Martin

[johnsta]

I'm getting HUGE numbers of defective files. What I believe is
happening (but haven't fully verified) is that whenever one of the
HDHR tuners changes channels, NRecord creates a defective recording.
Can you fix this?

[sub]

At least if you're getting lots of defective files, you shouldn't have any issues reproducing the issue to collect more info for me. With the write info about what is happening, we can definitely fix it.

Try creating a c:\temp directory, and set HKEY_LOCAL_MACHINE\Software\Wow6432Node\NPVR\ LogFileWriter=2 (DWORD), then reproduce the problem and post the normal logs and c:\temp\file-writer-*.txt files

This registry setting produces large log files in c:\temp. Remember to remove this registry setting later when you've finished catching logs.

[sub]

Actually, when you collect those logs, do it with this NPVRWriter.ax, which logs a little more info.

[johnsta]

> At least if you're getting lots of defective files, you shouldn't
> have any issues reproducing the issue to collect more info for
> me. With the write info about what is happening, we can definitely
> fix it.

> Try creating a c:\temp directory, and set
> HKEY_LOCAL_MACHINE\Software\Wow6432Node\NPVR\ LogFileWriter=2
> (DWORD), then reproduce the problem and post the normal logs and
> c:\temp\file-writer-*.txt files

> This registry setting produces large log files in
> c:\temp. Remember to remove this registry setting later when
> you've finished catching logs.

> Actually, when you collect those logs, do it with this
> NPVRWriter.ax, which logs a little more info.

> Attached Files File Type: zip NPVRWriter.zip (48.6 KB, 1
> views)

There's something going wrong with these txt files in c:\temp.

I started it up at 5:20 pm. It was creating about 1.5 mg of data per
minute, which was not a problem.

At 6 pm, there was a transition, where three recordings stopped and
three new recordings began. Two of the three new recordings were
defective.

Unfortunately, the system deleted the file that started at 5:20 pm,
and created an empty new one, starting at exactly 6pm -- which means
that all the data from the recording transition was lost.

Apparently the same thing happens at the top of every hour, exactly
when the transitions occur, so precisely the data that's needed is
being lost.

Could you tell me what's going on?

[sub]

This logging isn't really intended for what you're using it for, and files can get overwritten by later recordings, but it should be good enough though. Just after the completion of a recording (or simultaneous recordings), the file(s) will be there. I don't need all the files - hopefully you'll be able to catch one or two that related to a problem recording.