2018-01-31, 02:07 PM
Thread: Tuner card died -- looking for recommendations
https://forums.nextpvr.com/showthread.ph...post520628
That thread described replacing the Ceton card with an HD HomeRun box.
It also described some problems that I was having with defective TS
files recorded with both the Ceton and HDHomeRun configurations.
During the last week I've been doing a lot of research on this
problem, and I've identified what appear to be issues in NRecord. The
purpose of this thread is to document the results.
***
*** Introduction
***
As I described in the last thread, NRecord has produced some defective
TS files, and it's getting worse, to the point where it's becoming a
nightmare. The defective files display zero recording length in VLC:
- Partially defective TS files can be played in VLC because the
progress bar works (even though the hotkeys don't)
- Totally defective TS files can't be played at all in VLC.
As I described in the last thread, NPVR has been occasionally
producing partially defective TS files for months, but I blamed them
on the Ceton card. However, when I switched to an HDHR box in early
December and the same thing happened, it appeared that the problem was
in NPVR itself. It's hard to believe that both the Ceton card and the
HDHR box are producing the same problem, since one is electrically
connected to the I/O bus, but while the other transmits data through
the router over a network connection. Still, they have a common
component (the Comcast Cablecard), so that possibility has to be
considered.
Starting on December 26, there was a new development. Every recording
of the "WBZ News at 11" (at 11pm) was totally defective. Although
initially this was a really depressing discovery, it was actually a
gift from heaven, because it provided a platform where repeatable
tests could be performed.
In the last two weeks, I've been playing around with different tests,
and all these tests point to a bug in NRecord that's creating bad
TS files during the first few seconds that recording starts.
***
*** Test #1: Duplicate Recording Test
***
In this test, which I've tried several times, I create a manual
recording that records exactly the same show, "WBZ News at 11," as
a manual recording. Result:
- The recurring recording is totally defective, as usual.
- The manual record is not defective at all.
Both of these recordings are made by NRecord from the same tuner on
the same HDHR box, so they should produce the same results, but they
don't, indicating that NRecord is handling them differently.
Here are the ffprobe listings for the two TS files:
These two dumps should be virtually identical, but they aren't.
The first of these two dumps illustrates something that I've seen in
all the defective TS files: There are almost always additional
"Program N" sections, in addition to "Program 3".
Here's another piece of information: I've tested these TS files
immediately after they've started recording, as little as 15 seconds
later. It's clear that whether or not they're defective is determined
immediately when the the TS file is initialized by NRecord.
In the past, I assumed that some error was occurring at the end of the
recording session, that perhaps NRecord wasn't closing the file
properly. But these observations make it clear that whatever error is
occurring is occurring at the beginning of the session, at file
creation time, before data recording even begins.
***
*** Test #2: NRecord restart test
***
In this test, which I've also tried several times, I kill NRecord and
restart the service about around 10:45 pm.
Restarting NRecord should not have any effect on a recording beginning
at 11 pm, but it does. Result: The recording of "WBZ News at 11" is
not defective at all under these cirdumstances.
What this indicates to me is that NRecord is in some error state
that gets cleared when NRecord is restarted at 10:45 pm.
***
*** An unrelated bug: NRecord stops recording anything
***
This is a completely separate bug which, as far as I know: NRecord
simply stops recording. Several months ago, I set up a script that
wakes up every 60 seconds and checks the recording directory to see if
the TS file time stamps are being updated. If not, then it pops up an
alert telling me that NRecord has stopped recording, and I just kill
NRecord and restart the service.
While I was working on the defective file bug, I was "fortunate"
enough to see this other bug occur as it happened, and was able to see
what was happening.
The Comcast network went down for a few minutes, both cable tv and
internet. When Comcast came back up, NRecord didn't recover properly,
and simply stopped recording.
I don't know if there are any other reasons why NRecord would stop
recording, but this certainly seems to be one of them.
If I could make a suggestion, start up a background thread in NRecord
that sleeps but wakes up every 30-60 seconds to see if NRecord has
stopped recording and, if so, do something to start it up again.
***
*** Summary
***
I have some other test variations that I want to try in the next few
days, and I'll post additional information as I have it.
I realize that you probably don't support Windows 7 much any more, and
this may be a Windows 7 problem, for all I know.
But producing defective TS files is an absolute nightmare, and
anything you can tell me as workarounds either to prevent the problem
or to repair the files would be greatly appreciated.
For example, if you look at the ffprobe dump of the defective TS
files, all of them have a "Program 3" that looks correct, including
the correct duration, but the defective ones have one or more of
"Program N" that I assume are confusing VLC.
Is there some simple way, either using direct binary editing, or using
ffprobe or ffmpeg, set some internal pointer so that VLC will only see
Program 3?
Any workarounds of this kind would be appreciated. Thanks.
https://forums.nextpvr.com/showthread.ph...post520628
That thread described replacing the Ceton card with an HD HomeRun box.
It also described some problems that I was having with defective TS
files recorded with both the Ceton and HDHomeRun configurations.
During the last week I've been doing a lot of research on this
problem, and I've identified what appear to be issues in NRecord. The
purpose of this thread is to document the results.
***
*** Introduction
***
As I described in the last thread, NRecord has produced some defective
TS files, and it's getting worse, to the point where it's becoming a
nightmare. The defective files display zero recording length in VLC:
- Partially defective TS files can be played in VLC because the
progress bar works (even though the hotkeys don't)
- Totally defective TS files can't be played at all in VLC.
As I described in the last thread, NPVR has been occasionally
producing partially defective TS files for months, but I blamed them
on the Ceton card. However, when I switched to an HDHR box in early
December and the same thing happened, it appeared that the problem was
in NPVR itself. It's hard to believe that both the Ceton card and the
HDHR box are producing the same problem, since one is electrically
connected to the I/O bus, but while the other transmits data through
the router over a network connection. Still, they have a common
component (the Comcast Cablecard), so that possibility has to be
considered.
Starting on December 26, there was a new development. Every recording
of the "WBZ News at 11" (at 11pm) was totally defective. Although
initially this was a really depressing discovery, it was actually a
gift from heaven, because it provided a platform where repeatable
tests could be performed.
In the last two weeks, I've been playing around with different tests,
and all these tests point to a bug in NRecord that's creating bad
TS files during the first few seconds that recording starts.
***
*** Test #1: Duplicate Recording Test
***
In this test, which I've tried several times, I create a manual
recording that records exactly the same show, "WBZ News at 11," as
a manual recording. Result:
- The recurring recording is totally defective, as usual.
- The manual record is not defective at all.
Both of these recordings are made by NRecord from the same tuner on
the same HDHR box, so they should produce the same results, but they
don't, indicating that NRecord is handling them differently.
Here are the ffprobe listings for the two TS files:
Code:
--- ffprobe -hide_banner "d:\tv\shows\WBZ News at 11_20180125_23002335.ts"
[mpeg2video @ 000000000046f100] Invalid frame dimensions 0x0.
Last message repeated 13 times
[mpegts @ 00000000004655a0] PES packet size mismatch
Last message repeated 1 times
[mpegts @ 00000000004655a0] Could not find codec parameters
for stream 3 (Unknown: none): unknown codec
Consider increasing the value for the 'analyzeduration' and 'probesize' options
Input #0, mpegts, from 'd:\tv\shows\WBZ News at 11_20180125_23002335.ts':
Duration: 00:37:00.10, start: 21792.896522, bitrate: 3161 kb/s
Program 4
Program 3
Stream #0:0[0x1823]: Video: mpeg2video (Main) ([2][0][0][0] / 0x0002),
yuv420p(tv, top first), 720x480 [SAR 8:9 DAR 4:3],
Closed Captions, 29.97 fps, 29.97 tbr, 90k tbn, 59.94 tbc
Stream #0:1[0x1824](eng): Audio: ac3 (AC-3 / 0x332D4341),
48000 Hz, 5.1(side), fltp, 384 kb/s
Stream #0:2[0x1825](spa): Audio: ac3 (AC-3 / 0x332D4341),
48000 Hz, stereo, fltp, 192 kb/s
No Program
Stream #0:3[0x17e9]: Unknown: none
Unsupported codec with id 0 for input stream 3
--- ffprobe -hide_banner "d:\tv\shows\WBZNews-11_20180125_23002340.ts"
[mpeg2video @ 00000000002ddfe0] Invalid frame dimensions 0x0.
Last message repeated 13 times
[mpegts @ 00000000002d55a0] PES packet size mismatch
Last message repeated 1 times
Input #0, mpegts, from 'd:\tv\shows\WBZNews-11_20180125_23002340.ts':
Duration: 00:42:00.40, start: 21792.896522, bitrate: 3118 kb/s
Program 3
Stream #0:0[0x1823]: Video: mpeg2video (Main) ([2][0][0][0] / 0x0002),
yuv420p(tv, top first), 720x480 [SAR 8:9 DAR 4:3],
Closed Captions, 29.97 fps, 29.97 tbr, 90k tbn, 59.94 tbc
Stream #0:1[0x1824](eng): Audio: ac3 (AC-3 / 0x332D4341),
48000 Hz, 5.1(side), fltp, 384 kb/s
Stream #0:2[0x1825](spa): Audio: ac3 (AC-3 / 0x332D4341),
48000 Hz, stereo, fltp, 192 kb/sThese two dumps should be virtually identical, but they aren't.
The first of these two dumps illustrates something that I've seen in
all the defective TS files: There are almost always additional
"Program N" sections, in addition to "Program 3".
Here's another piece of information: I've tested these TS files
immediately after they've started recording, as little as 15 seconds
later. It's clear that whether or not they're defective is determined
immediately when the the TS file is initialized by NRecord.
In the past, I assumed that some error was occurring at the end of the
recording session, that perhaps NRecord wasn't closing the file
properly. But these observations make it clear that whatever error is
occurring is occurring at the beginning of the session, at file
creation time, before data recording even begins.
***
*** Test #2: NRecord restart test
***
In this test, which I've also tried several times, I kill NRecord and
restart the service about around 10:45 pm.
Restarting NRecord should not have any effect on a recording beginning
at 11 pm, but it does. Result: The recording of "WBZ News at 11" is
not defective at all under these cirdumstances.
What this indicates to me is that NRecord is in some error state
that gets cleared when NRecord is restarted at 10:45 pm.
***
*** An unrelated bug: NRecord stops recording anything
***
This is a completely separate bug which, as far as I know: NRecord
simply stops recording. Several months ago, I set up a script that
wakes up every 60 seconds and checks the recording directory to see if
the TS file time stamps are being updated. If not, then it pops up an
alert telling me that NRecord has stopped recording, and I just kill
NRecord and restart the service.
While I was working on the defective file bug, I was "fortunate"
enough to see this other bug occur as it happened, and was able to see
what was happening.
The Comcast network went down for a few minutes, both cable tv and
internet. When Comcast came back up, NRecord didn't recover properly,
and simply stopped recording.
I don't know if there are any other reasons why NRecord would stop
recording, but this certainly seems to be one of them.
If I could make a suggestion, start up a background thread in NRecord
that sleeps but wakes up every 30-60 seconds to see if NRecord has
stopped recording and, if so, do something to start it up again.
***
*** Summary
***
I have some other test variations that I want to try in the next few
days, and I'll post additional information as I have it.
I realize that you probably don't support Windows 7 much any more, and
this may be a Windows 7 problem, for all I know.
But producing defective TS files is an absolute nightmare, and
anything you can tell me as workarounds either to prevent the problem
or to repair the files would be greatly appreciated.
For example, if you look at the ffprobe dump of the defective TS
files, all of them have a "Program 3" that looks correct, including
the correct duration, but the defective ones have one or more of
"Program N" that I assume are confusing VLC.
Is there some simple way, either using direct binary editing, or using
ffprobe or ffmpeg, set some internal pointer so that VLC will only see
Program 3?
Any workarounds of this kind would be appreciated. Thanks.
