Tuner card died -- looking for recommendations

[BrettB]

For example, it says, "Click on the QAM/ATSC/DVB-T/DVB-C Silicondust
HDHomeRun Tuner xxxxxxxx-0 entry appropriate for your signal source
and then click Device Setup. Do not use the HDHR entry."

Unfortunately, none of that matched the NPVR screen, so I used the
"HDHR entry" anyway, and that ended up working. I had to screw around
with both of them for a couple of hours, but it finally worked.

FYI (or for others finding this in the future): If you're using a Cable Card, then you select the HDHR devices. If you were using OTA broadcast in the US, you would use the ATSC devices. If you were using Digital Cable (QAM), then you would use the QAM devices.

After that, the main problem is that all the recurring programs are
set up for the Ceton card, and they're wrong for the HD box, since
they used different tuners and sometimes different channel names.

I ended up writing a script that would generate and execute the
correct sql to make the changes automatically. So for example the
command "fixchannel WCVB5 WCVB" would find all recurring programs
using the old channel name (WCVB5) and change them to point to the new
channel name (WCVB). This worked pretty well, though it still took a
number of hours to get it right. I don't know if there's a way to do
it automatically within the UI, but this worked out ok. The only
other way of doing it, as far as I know, would be to manually cancel
all the old recurring shows and manually reschedule the same shows
again using the new channels. Since I have dozens of recurring shows
scheduled, this would have been extremely tedious, time-consuming and
error-prone. Anyway, all's well that ends well.

The supported way to accomplish this would be to use the NextPVR Settings to Merge the old Ceton channel with the corresponding new HDHR channel. Then all of the recurring recordings would "just work."

[johnsta]

Good to know!

[mvallevand]

We probably need a sample file with the problem uploaded and linked on the cloud. The smaller the better.

The simplest file fixer for common stream problems is ts4np.

And Silicon Dust did announce a 6 tuner Prime at CES.

Martin

[DVRMultiStreamer]

Thanks for reviving this thread. I've been planning to document my
own experiences with moving from the Ceton card to the HD HomeRun, and
this has motivated me finally to do it.

So it really sucks that the HD only records 3 shows at a time, while
the Ceton card recorded 4 shows at a time. That means that, like
other people here, I would have to get another HD box, and another
Comcast cablecard. The good news is that this would allow me to
record more shows, since I could now record six at a time. The bad
news is that this would allow me to record more shows, since I could
now record six at a time, and so this would feed into my compulsive
obsession to record shows and watch them later. I'm now over a year
behind in watching prime time shows, so getting a second HD box would
cause me to have to buy more disk space to save a lot more shows that,
with war over North Korea pending, I may never see anyway. So for the
time being I'm making do with one HD box, but I'm dreading February
sweeps that start next week, when there will be a lot more conflicts.

There's one major bug that didn't go away when the HD box as
I had hoped it would.

About 10% of the recorded TS files apparently have some header field
filled in wrong. In Windows explorer, these files with the Ceton card
showed a length of 0, or else a length of something like 22:00:00.
Windows explorer doesn't display the length of any of the TS files
recorded with the HD card, but the basic problem is the same.

These files can't be played in Windows Media Player at all.

They can be played in VLC, but VLC shows a zero file length, and the
hotkeys don't work. However, the progress bar amazingly does work,
and you can click on it to move around the file. So that's a
workaround, but it's difficult and inconvenient to use.

As I said, I had assumed that this was a bug in the Ceton card, but
since it's still happening, I assume it's a bug in the NPVR software,
or at least in some Windows 7 component that Windows Media Center and
NPVR both use.

So I have two questions. First, is there any way to keep this from
happening?

And second, is there some utility program that can repair these TS
files? Since they actually play correctly under VLC, it appears that
the files are OK except for some header field. Alternatively, can I
do a binary edit on the file and make a simple correction in some way?

Any help with this problem would be appreciated.

Like you I also had somewhat of a major TV recording addiction to where I was recording too much and not enough time to watch. I think my backlog is more into a few years as I started recording stuff since 2012 in HD. Sometimes because the filenames don't have a descriptive TV show title it can be time consuming to name them all manually and sort them out. I used to use WinTV until the main system crashed but it recorded the CH number and CallSign in the filename making it easier to sort by Channels and knowing what shows occur in each station also helps narrow down what shows they are.

I used to manually start and end the shows with the WinTV record button because when I had previously used the scheduler in the past I found a lot of corrupted video files that won't play with VLC but could with WinTV. So now NextPVR has made scheduling a little easier but I still have to use Manual Recording and set the start and end time. It would be nice when setting the start time that the end time hour adjust itself to match ten minutes after the start time. When programming a series of hourly programs on the same channel it gets time consuming making 1 hour recording chunks on the same channel.

It would nicer if smaller time increments of 1 minute or 10 seconds could be done to shorten pre and post padding to be more accurate. Also actual start and ends times are better for certain shows that start not on the hour but on a strange minutes like 1135, 1237, or 207 for some late shows.


For example if the show started at 10AM and ended at 11AM
I make a series of show programs 11AM to 12PM, 12PM to 1PM ....
10PM to 11PM it gets to a point where I'm scrolling from the current time of 9AM all the way to 11PM to set the end time. It would be wiser if you set the start time to 10PM that the end time should auto switch from 9AM to 1010PM s you only have to switch to 1020PM, 1030PM, 1040PM, 1050PM, and finally 1100PM instead of advancing the end time starting from 10AM all the way to 11PM which can be time consuming. Manual entry would be better here as well.


Now the recording with video corruption I think I know what you are talking about. When recording with NextPVR some files may not play in VLC due to some sort of corruption when tuners conflict and the recording does something funny and can't record properly. I believe this same corruption is also possibly caused by the hard drive spin up time preventing it from writing to the drive on time and if this happen the beginning of the file is blank and sometimes after it goes through the dead seconds of not recording a signal you will see the video start. Other times this nukes the video play so VLC can't it at all and you need another decoder player to watch it properly. The only way to avoid it is to constantly record something to the drive so it never spins down.

However, I have been meaning to ask the SUB to include a new feature to fix this drive delay bug.

For example when you are recording a show and say the last recording has stopped for over 30 mins enough time for a hard drive to spin down.

When the recording starts hours later there is a this hard drive spin up time delay sometimes up to 30 seconds from a cold sleep.

The OP could include a pre read hard drive check 1 minute before any recording time to kick start the hard drive so it is awake and ready. This spin down issue usually happens more with USB external hard drives. I tend to use these a lot for convenience for moving massive amounts of storage from one system to another. Hooking a drive internally won't work for me since I use XP and I use a special USB sector emulator to use 8TB and later 16TB drives when they come out externally via USB.

Some hard drives may not spin up with just a directory read or peeking at the hard drive and may require writing like some small ascii text file 1 Byte to wake it up in time for the recording to start. I'm hoping a Read drive solution is possible to be included in the Recording section as a check box to wake up the drive selected in the recording window.

Another problem I noticed is there is no real time status of your Hard Drive space remaining. It would be nice to have this show up on the display screen on the Main Menu or Live TV viewing for example if you had two hard drives installed.

C: 500.0GB remaining
C:\NEXTPVRVIDS\
[Recording Now] TV Show Name 1-- Ch2_FOX_2018-1-21-2000_2100.ts
Elapsed Recording Time: 15mins 30seconds

D: 900.0MB remaining - WARNING LOW DISK SPACE (in blinking RED)
D:\NEXTPVRVIDS\
[Recording Now] TV Show Name 2 -- Ch5_CBS_2018-1-21-2000_2100.ts
Elapsed Recording Time: 15mins 30seconds


Often times a recording may run out of space and I won't find out till later. It would nice to see what show is being recorded currently, how long, what location it is stored, and the drive space left on the top of the screen as an overlay.

Another thing I noticed is you can't preselect a destination hard drive for each recording like I could for WinTV. In theory you could preassign each Channel to a different Drive and Drive directory to save the recordings.

If you had two 8TB drives and say planned to be out of the country for a good chunk of time. If you could record one channel to one hard drive, and another channel to another channel that would guarantee you won't run out of space on one hard drive or have a recording clipped short because they ran out of space at the same time.

The recording to another drive letter with more space I'm not sure how this works. Does it wait for Drive 1 to run out of space before starting new recording to Drive 2 or does it juggle back and forth between Drive 1 and Drive 2 with recordings as one Drive will always have more space than the other at a given time?



Another feature could be writing to a Ramdrive and after the recording is done move the video file to a hard drive. A Ramdrive will always be ready and on and never sleep so the recording should not be affected. The only thing is having a large enough Ramdrive. With a 32GB setup or 64GB for newer systems you could allocate 24GB or 56GB as a pure Ramdrive leaving about 8GB for the OS to run properly.

But at the moment there is no automated move file to new location after the recording is done option.

And you have to be careful of how big and how long the recording is. Usually 8GB max per 1 hour. So if you have a 3 Hour show = 24GB max so you can't record too many channels to a Ramdrive first before it is moved off to a hard drive. Newer systems with 64GB may make multiple video recordings to a Ramdrive before moving possible.


As for repairing corrupted videos I tried splicing it before and I think it didn't work. You might try to open the file in a video editor and cut the portion visible and then output it back and see if VLC sees it. But you would be reencoding the file so probably some quality loss.

[johnsta]

Well, thanks for posting that. It's nice to know that there's
somebody else in the world with the same "Obsessive Compulsive
Recording Disorder" that I have.

[johnsta]

Hi Martin,

> We probably need a sample file with the problem uploaded and
> linked on the cloud. The smaller the better.

The smallest file with this problem that I could readily find
is a half-hour recording (562M).

I tried making 20 quick recordings, each less than a minute, but the
problem didn't occur with those. It's a random problem, so I don't
know if it just didn't hit those by chance, or if the bug only occurs
with longer recordings. I'll try making some more short recordings
later today.

I have other options. For example, from 562M file mentioned above I
could give you a hex dump of the first and last 1000 bytes, if that
would be enough.

**** ADDITIONAL INFORMATION

I just discovered that this bug is happening consistently with one
particular program -- "WBZ News at 11". Almost every one of these
files has the bug and, even worse, I can't play them at all, even with
VLC, which makes this problem a lot more serious, since there's
no workaround.

Looking at the files in Windows explorer (the actual length of these
shows is about 38 minutes):

* 1/19 show, length=5:38:09, size=886,735KB - won't play in vlc at all
* 1/17 show, length=blank, size=884,799KB - won't play in vlc at all
* Almost all of the other files are similar to this

* Two exceptions:
* 1/4 show, length=blank, size=1,010,049KB -- PLAYS ON VLC NORMALLY
VLC shows program length of 37:59
* 12/31 show, length=blank, size=920,036KB -- PLAYS ON VLC NORMALLY

So the bug appears to be 95% repeatable for this program (WBZ News at
11). The size discrepancies suggest that NPVR is failing to write
several tens of thousands of bytes to the end of the file most of the
time, but not always.

Please tell me what I need to send you, and how to send it to you.

Thanks,

John

[Graham]

I just discovered that this bug is happening consistently with one
particular program -- "WBZ News at 11". Almost every one of these
files has the bug and, even worse, I can't play them at all, even with
VLC

Are you able to use the HDHR software to monitor the signal that is being received by the tuner while recording this show? It may show glitches in the stream received by the tuner.

Simply stated, NextPVR copies the stream received from the tuner unchanged to a recording file on the computer ... the most likely explanation for glitchy recordings is a glitchy input to the tuner.

[sub]

So the bug appears to be 95% repeatable for this program (WBZ News at
11). The size discrepancies suggest that NPVR is failing to write
several tens of thousands of bytes to the end of the file most of the
time, but not always.

Please tell me what I need to send you, and how to send it to you.

If you can copy one of the recordings to somewhere like onedrive or dropbox or google drive, and let use know the download link, we'll take a look at the file.

[johnsta]

> Simply stated, NextPVR copies the stream received from the tuner
> unchanged to a recording file on the computer ... the most likely
> explanation for glitchy recordings is a glitchy input to the
> tuner.

As I said before, this problem has occurred with both the Ceton card
and the HDHR box, ever since I installed NPVR in May 2016.

The problems with the "WBZ News at 11" are new, and repeatable. These
files cannot be played at all on vlc.

However, I just found a file of a network program recorded on
12/26/2017 (three weeks ago) with the HDHR box. Windows explorer
shows: length=26:29:45 (the actual length is an hour),
size=1,375,216KB.

The above program does play OK on vlc. It shows a length of 00:00,
and the hotkeys don't work, but the progress bar does work, and you
can watch the entire program, and the video and sound are great.

This is exactly what happened with the Ceton card. So I don't think
that this is a transmission problem.

At this point, what I think it has to be is a bug in either NPRV or in
some Windows 7 component that was used by NPRV with both the Ceton
card and the HDHR box.

So here are the files that I have isolated (previously described):

- A 1/2 hour program recorded in Nov 2016 that plays in VLC, showing
zero length, where the hotkeys don't work but the progress bar does.

- A one hour program recorded on Dec 26 2017 (described four
paragraphs up) that also plays in VLC the same way.

- A big collection of "WBZ News at 11" files, running back to December,
described in my last posting, where almost also failed completely
and could not even be played on VLC.

Just tell me what I can send you and how I can send it to you.

[sub]

The above program does play OK on vlc. It shows a length of 00:00

This is unlikely to be anything NextPVR is doing. It's just copying the digital stream supplied by the device. Often players will look at the first timestamp in a .ts file, and the last timestamp in the file, to determine the duration, and this is ultimately used while skipping etc. It's likely something like the broadcaster has spliced together different content during this show, and the end timestamp is smaller than the start timestamp, so VLC can't determine the duration, so reports 00:00. Transport stream files from broadcast sources are notorious for having these types of issues.

Ultimately though, I do try to make sure NextPVR's own player can handle these types of scenarios, so you should get a more accurate duration reported there.