or Connect
AVS › AVS Forum › Video Components › Home Theater Computers › HDHomeRun - Dual ATSC or QAM to Ethernet Box
New Posts  All Forums:Forum Nav:

HDHomeRun - Dual ATSC or QAM to Ethernet Box - Page 25

post #721 of 1962
I read through all 25 pages of this thread and I am a little confused about just exactly what "2 tuners" means. There was some talk about splitting the input from a cable to the HDHR that confused me. Suppose I connect a roof antenna to one input and a cable to the other input. Can I:

1. Record one QAM and one OTA simultaneously? (I think I can.)

2. Record two QAM simultaneously?

3. Record 2 OTA simultaneously?

If the answer to 2 and 3 is NO, then let's suppose I give up OTA. Do I need to split the QAM cable and connect it to both ports?
post #722 of 1962
Quote:
Originally Posted by Dick Kalagher View Post

I read through all 25 pages of this thread and I am a little confused about just exactly what "2 tuners" means. There was some talk about splitting the input from a cable to the HDHR that confused me. Suppose I connect a roof antenna to one input and a cable to the other input. Can I:

1. Record one QAM and one OTA simultaneously? (I think I can.)

2. Record two QAM simultaneously?

3. Record 2 OTA simultaneously?

If the answer to 2 and 3 is NO, then let's suppose I give up OTA. Do I need to split the QAM cable and connect it to both ports?

You can't use one tuner in it for OTA and one tuner in it for QAM in MCE, but you can in some other solutions. It has no internal splitter, so if you're feeding it a cable, you'll need to split it to provide a signal to both tuners.
post #723 of 1962
Quote:
Originally Posted by james_k_p View Post

Hey Everyone, I'm new to this. So a few redundant questions I hope someone can answer for me. I'm looking to record HDTV, via OTA or QAM. (nfl football games for my personal archiving). If I get this device, on XP Pro, I could accomplish this?

Yes for OTA. In the case of QAM: Yes but only unencrypted QAM.

Quote:
Originally Posted by james_k_p View Post

What format do these programs record to?

Depends on the program... Most support transport stream. Some can do program stream or dvr-ms. Most allow you to do post processing to transcode to another format. The HDHomeRun command line program actually has a "save" feature that dumps the raw transport stream (full or filtered to a single program).

Quote:
Originally Posted by james_k_p View Post

Say SageTV?

Don't know about SageTV, sorry. I would assume native transport stream support.

Quote:
Originally Posted by james_k_p View Post

I've heard people say VLC can record?

Yes... and much more... (view/record at the same time, rebroadcast, transcode... etc).

Quote:
Originally Posted by james_k_p View Post

So the VLC media player has a record feature?

Yes, run the "File ... Wizard" and choose "Transcode/Save to file". There are other ways as well... command line options etc.. check the help files.

Quote:
Originally Posted by james_k_p View Post

Or is there another VLC program I am uninformed about?

There is server version (to put it VERY simply) but that's not what you meant. The one you know of is all you need.

Quote:
Originally Posted by james_k_p View Post

I want to record, then be able to save it and burn to a dvd. Preferrably, storing it in MKV files. No, I'm not looking to actually make a dvd player playable DVD, just dvd for storage reasons like I do with x.264 files I download. Thanks.

For MKV you will probably need to transcode but it can be done.
post #724 of 1962
(hopefully posting in the correct thread)

I understand the HDHR does not perform any encoding/decoding: Digital stream in/digital stream out.

I saw a post of a Dual Core PC utilization at 30%.

My PCs are slow (Celeron 1.1GHz, 512RAM,WinXP ProSP2), I use an analog PVR with hardware Decoding (AverMedia). I use S-Video out to the SD TV from an ATI 9250 128mb card.

Are the following assumptions correct?:
From my PVR PC: Passthrough the video stream from HDHR to the TV with very little system requirements?
Record programming into this PVR PC with very little system requirements?
Playback recorded programming will be a huge drag on this PVR PC?
Could I playback (decode) recorded HDHR programming through my analog tuner to relieve the resource drag?
Is does work with WinXP Pro SP2? Site only lists MCE & Vista as beta.

TIA
post #725 of 1962
> Suppose I connect a roof antenna to one input and a cable to the other input.
> Can I:
> 1. Record one QAM and one OTA simultaneously? (I think I can.)

yes

> 2. Record two QAM simultaneously?

To do this you need to split the cable and connect it to both tuners.

> 3. Record 2 OTA simultaneously?

To do this you need to split the antenna feed and connect it to both tuners.

You could split both the antenna feed and the cable feed, and connect
both to switch boxes, and connect the switch boxes to the tuner inputs.
A Manual 2 or 3-way switch is under US$5. One with an IR remote is
under US$30.
post #726 of 1962
> I understand the HDHR does not perform any encoding/decoding

Correct, the TV station does the encoding. You get a mpeg2ts
stream.

> From my PVR PC: Passthrough the video stream from HDHR to the TV
> with very little system requirements?

Only if you have a TV that accepts mpeg2ts streams.

> Record programming into this PVR PC with very little system requirements?

Yes. This is just copying bits from Ethernet to disk.

> Could I playback (decode) recorded HDHR programming through my analog tuner
> to relieve the resource drag?

If your analog tuner can decode a 19.39 MB/s mpeg2ts stream and scale it down
to 720x480 in real time it should work. But I doubt that your tuner can do that.
You will probably have to downconvert the HD channels to SD using the CPU (not in
real time), then play the new file using the analog tuner. You may be able
to watch SD programming without the conversion step.
post #727 of 1962
Does anyone have minimum system requirements for proper use of this IP Box?

Posted in this thread mentions PIII w/256MB as minimum.
However most other posters in this thread have issues with 2.xGHz.

Wondering if (sounds doubtful) it will work with
Celeron 1.1GHz
512MB Ram
Avermedia M179 Hardware Decoder
ATI 9250 128mb Video Card controlling S-Video out to SD TV
10/100 Router (I've achieved up to 13GB/hr transfer rate)
post #728 of 1962
I dont think that system will be enough. Network wise, 100Mb is fine for 2 HD streams. As for computer, find a 1080i transport stream or program stream test file to download and try.
post #729 of 1962
I am planning to set up my new HD HR as follows:

10/100/802.11g router >> 10/100 switch >> HDHR and HTPC plugged into switch

My knowledge of how a network works is pretty bad, so is this an okay way to set it up? I am worried that if I am using both tuners at the same time, since there is only one CAT5 cable connecting the switch to the network, will the data streams of the two shows have to travel to the router and back from the router on the same plug, thus making the data rate too high for the network?
post #730 of 1962
If your HTPC has a 100Mbps adapter connected to the switch you should be fine recording two simultaneous streams over your single connection.

With both the HD-HR and HT-PC connected to the switch your router should not be involved in this traffic at all. The switch will take care of it.

The router is there to handle traffic to things not directly connected to the switch (presumably the internet).
post #731 of 1962
Thanks Gerhard, that is what I thought, but wanted to make sure!
post #732 of 1962
Dear All:

I just bought a HDHR online and got it set up with my XP pro. After I located a unencrypted HD channel and launched VLC. It only showed 4:3 instead of 16:9. After playing with HDHR GUI and VLC, I just couldn't get it right. Is it because of the unencrypted signal is 4:3 or some tricks I missed? Any suggestion? Thanks in advance!
post #733 of 1962
masama, It may be a SD channel that is being broadcast digitally. The HDHomeRun can receive any unencrypted digital channel, SD or HD. I get GolfTV and a few others that are SD and 4:3 aspect.
post #734 of 1962
Quote:
Originally Posted by vladd View Post

masama, It may be a SD channel that is being broadcast digitally. The HDHomeRun can receive any unencrypted digital channel, SD or HD. I get GolfTV and a few others that are SD and 4:3 aspect.


Vladd, thanks for your reply. You are right about that. What I got was SD broadcasted digitally. After I scanned up to 110+, I got quite a few HD channels in 16:9. The quality is amazing!
post #735 of 1962
I finally got my HDHR and I am having some bittersweet feelings about it.

The good:

It works. I can view and record all 6 of my local channels with no problems.

The Bad:

The recorded streams are full of errors. The m2r logs look like a book and there are on an average of 50-70 video errors per every 10 minutes of recording. I know its not my QAM signal since the MyHD130 can record all those channels perfectly.

The culprit is the network interface. Even the best, clean, and non-traffic network has too many errors to allow a clean stream to be recorded.

I tried recording on both a PC and a Mac and nothing seemed to make the errors go away.
post #736 of 1962
> The culprit is the network interface. Even the best, clean, and
> non-traffic network has too many errors to allow a clean stream
> to be recorded.

The default is to transfer the mpeg data using UDP, which is
unreliable (by design). When a packet gets dropped, you lose.

You can use TCP to transfer the mpeg data by setting the target
to tcp://IP_ADDR:PORT_NUMBER
Then if a packet gets dropped, TCP will retransmit it.

Even so, there are problems. The HDHR's network stack is buggy.
(Run tcpdump (or whatever OS-X calls their version) and wade through
it.) The HDHR's firmware isn't open source, so end-users can't fix it.
The HDHR does not have a big enough transmit buffer. The computer
receiving the mpeg data MUST service the Ethernet VERY frequently or
data is lost.

I got a significant improvement by turning off the Nagle algorithm.
(On the receiving computer.) Also, set the TCP receive buffer
on the computer to a VERY large value. I use 100000000 (100 MB).
Nice up the process that is reading the data from Ethernet. Give
each tuner its own disk drive (seeks are very slow). You might
not be able to watch the program while recording, depending on
your hardware. Hopefully it goes without saying to use a wired
Ethernet, not wireless.

I can sometimes get a 100% perfect file, so it *is* possible.
But not always. Any latency reading the Ethernet, even once,
will lose data. And that is very difficult to achieve with a
general purpose computer that doesn't provide true real-time
facilities.

Silicondust knows about the problems. Posts about the problem
on the Silicondust web forums are either moved to a private
forum, or deleted altogether. Wouldn't want to scare off
potential customers. They could use the network stack from
one of the BSDs, and make the transmit buffer larger, and
this problem would mostly go away.
post #737 of 1962
Quote:
Originally Posted by Dieter2 View Post

You can use TCP to transfer the mpeg data by setting the target
to tcp://IP_ADDR:PORT_NUMBER
Then if a packet gets dropped, TCP will retransmit it.

You got me curious about this. How exactly do you do this? What port does HDHR use?
post #738 of 1962
Quote:
Originally Posted by Dieter2 View Post

I can sometimes get a 100% perfect file, so it *is* possible.
But not always...

Man, I don't know what the heck you guys are talking about. I don't have any kind of fancy ether-network gear, nor do I coddle the HDHR--I even stream HD videos to my media player on the same subnet, and with the same computer (& NIC & switch) that is capturing an OTA HD show via the HDHR. In dozens of recordings I've had one noticeable pixellation which I am confident was a signal problem.

But I have never seen a network problem. I haunt the Silicondust forum and if this is a widespread issue it is certainly news to me...
post #739 of 1962
Quote:
Originally Posted by Laserfan View Post

Man, I don't know what the heck you guys are talking about. I don't have any kind of fancy ether-network gear, nor do I coddle the HDHR--I even stream HD videos to my media player on the same subnet, and with the same computer (& NIC & switch) that is capturing an OTA HD show via the HDHR. In dozens of recordings I've had one noticeable pixellation which I am confident was a signal problem.

Have you run any of your recording through a m2r (mpeg2repair) log to see how clean they actually are?

The streams coming out of the MyHD are coming out completely 100% clean. Same channel on the same cable connection come out dirty (full of errors) on the HDHR. If everything is equal and the only thing different is the recording device then I have to blame the network for the problems.

I have changed numerous things and i still can't get a clean recording.
post #740 of 1962
Quote:
Originally Posted by Laserfan View Post

Man, I don't know what the heck you guys are talking about. I don't have any kind of fancy ether-network gear, nor do I coddle the HDHR--I even stream HD videos to my media player on the same subnet, and with the same computer (& NIC & switch) that is capturing an OTA HD show via the HDHR. In dozens of recordings I've had one noticeable pixellation which I am confident was a signal problem.

But I have never seen a network problem. I haunt the Silicondust forum and if this is a widespread issue it is certainly news to me...

Being new to the HD-HR but having made quite a few recordings over the 2 weeks I have had it but having had the opportunity to watch but a few, I got nervous I might have a problem.

I went in search of some evidence or answers on the Silicon Dust forum and the only thing I could come up with was this post cautioning about the pitfalls of using TCP.

I won't dismiss the possibility that posts have been hidden or moved but I don't think it's time to panic just yet.

post #741 of 1962
>> You can use TCP to transfer the mpeg data by setting the target
>> to tcp://IP_ADDR:PORT_NUMBER
>> Then if a packet gets dropped, TCP will retransmit it.
>
> You got me curious about this. How exactly do you do this? What port does HDHR use?

Here is the command I use:

hdhomerun_config ${HOMERUN_ID} set /${TUNER}/target tcp://${IP_ADDR}:${PORT}

Sources for the hdhomerun_config command are on silicondust.com.
They should compile okay on OS-X.

HOMERUN_ID is the IP address of the HDHR
TUNER=tuner0 (or tuner1)
IP_ADDR is the IP address of the computer
PORT is the TCP port number you want to use

The HDHR will send the mpeg data to whatever port number you tell it to.
Pick a port number that isn't already in use, and have the process
receiving the mpeg data listen on that port. Once the process is
listening to the port, set the HDHR's target with the command above.

The hdhomerun_config command can also set the channel number, filter,
get debug info, etc.

If you use TCP, and "get debug" says "neterr=0", there were no network
errors. (I suspect that "neterr=0" is meaningless with UDP, since the
HDHR would have no way to know that a packet got dropped.)
post #742 of 1962
If you are using an nForce 4 motherboard with onboard nic, make sure you have the checksum feature turned off. See http://www.silicondust.com/forum/viewtopic.php?t=3272

As for posts being removed: Since they moved to the new servers, the threads are automatically pruned after a period on inactivity (I don't know how long the period is). This is for server performance and space, not to "silence" anyone.
post #743 of 1962
Some people are so quick to jump to conspiracy theories, because their problems. I don't know about you guys, but I have 2 HDHR's, giving me 4 tuners and even when I have 3 streams being recorded at the same time, I have not had any glitches when watching the recordings. I don't know what m2r is, but I figure if I can watch the recordings with no stuttering or audio issues, they seem to be fine.
post #744 of 1962
m2r I would assume is MPEG2Repair. As a test, I decided to run a few files through it. All files were created with the hdhomerun_config "save" option to eliminate any issues with muxers etc. and give me a reading on the raw dump. This is after tuning to a channel and filtering a program. I consistenly got clean recordings except for a single video frame at the end of the file which is expected when using -C. The only exception to this is the following:
Code:
File Size Processed: 2.06 GB, Play Time: 00h:17m:02s
1920 x 1080, 29.97 fps, 18.90 Mbps (16.26 Mbps Average).
Average Video Quality: 66.22 KB/Frame, 0.26 Bits/Pixel.
AC3 Audio: 3/2 Channels (L, C, R, SL, SR) + LFE, 48.0 kHz, 384 kbps.
Dialog Normalization: -27.0 dB, Center Mix Level: -3.0 dB, Surround Mix Level: -3.0 dB
1 of 30657 video frames found with errors.
0 of 31960 audio frames found with errors.
16 corrupted video bytes in file.
0.000000 seconds of video timestamp gaps.
0.002289 seconds of audio timestamp gaps
The single video frame error again came at the end of the file. The only other problems were 2 audio timestamp gaps resulting in the total timestamp gap that you see.
post #745 of 1962
Quote:
Originally Posted by vladd View Post

m2r I would assume is MPEG2Repair. As a test, I decided to run a few files through it. All files were created with the hdhomerun_config "save" option to eliminate any issues with muxers etc. and give me a reading on the raw dump. This is after tuning to a channel and filtering a program. I consistenly got clean recordings except for a single video frame at the end of the file which is expected when using -C. The only exception to this is the following:
Code:
File Size Processed: 2.06 GB, Play Time: 00h:17m:02s
1920 x 1080, 29.97 fps, 18.90 Mbps (16.26 Mbps Average).
Average Video Quality: 66.22 KB/Frame, 0.26 Bits/Pixel.
AC3 Audio: 3/2 Channels (L, C, R, SL, SR) + LFE, 48.0 kHz, 384 kbps.
Dialog Normalization: -27.0 dB, Center Mix Level: -3.0 dB, Surround Mix Level: -3.0 dB
1 of 30657 video frames found with errors.
0 of 31960 audio frames found with errors.
16 corrupted video bytes in file.
0.000000 seconds of video timestamp gaps.
0.002289 seconds of audio timestamp gaps
The single video frame error again came at the end of the file. The only other problems were 2 audio timestamp gaps resulting in the total timestamp gap that you see.

I could live with those logs. That is about as close to perfect as you can get on any of the MyHD streams I record.

But here is my latest HDHR log:

Code:
File Size Processed: 8.55 GB, Play Time: 01h:14m:14s
1920 x 1080, 29.97 fps (26.84 fps Telecine), 38.81 Mbps (15.65 Mbps Average).
Average Video Quality: 71.15 KB/Frame, 0.28 Bits/Pixel.
AC3 Audio: 3/2 Channels (L, C, R, SL, SR) + LFE, 48.0 kHz, 384 kbps.
Dialog Normalization: -31.0 dB, Center Mix Level: -3.0 dB, Surround Mix Level: -3.0 dB
2610 of 119580 video frames found with errors.
1594 of 139205 audio frames found with errors.
25529945 corrupted video bytes in file.
17.584700 seconds of video timestamp gaps.
49.990901 seconds of audio timestamp gaps.
Like I said before, its a network issue that I cannot seem to fix.
post #746 of 1962
Quote:
Originally Posted by vladd View Post

All files were created with the hdhomerun_config "save" option to eliminate any issues with muxers etc. and give me a reading on the raw dump.

Can you give me a full example of that "save" command? I want to try it to narrow down the network issue.
post #747 of 1962
Sure.

Code:
hdhomerun_config.exe FFFFFFFF save 0 filename.ts
Just change "0" to "1" for tuner 1 and if you want to use directory or filenames with spaces, just encapsulate the filename (with path if necessary) in quotes.

Code:
hdhomerun_config.exe FFFFFFFF save 0 "c:\\long directory name\\filename.ts"
You can also use the device ID instead of "FFFFFFFF". You will need to if you have multiple devices.

Edit: You may want to check out http://www.yale.edu/pclt/rcorder/Readme.html
It's a 3rd party utility for tuning, filtering and recording from a single command line. It's just a wrapper for the hdhomerun_config.exe but saves you from having to do multiple commands.
post #748 of 1962
Thanks. I am trying them all now and I will see if I can narrow a few things down.
post #749 of 1962
I am getting closer. All these errors occurred in the first 8 seconds and then nothing else till the very end. So, 2 full minutes of no errors.

Code:
File Size Processed: 619.81 MB, Play Time: 00h:02m:13s
1920 x 1080, 29.97 fps, 38.81 Mbps (15.06 Mbps Average).
Average Video Quality: 61.32 KB/Frame, 0.24 Bits/Pixel.
AC3 Audio: 3/2 Channels (L, C, R, SL, SR) + LFE, 48.0 kHz, 448 kbps.
Dialog Normalization: -27.0 dB, Center Mix Level: -3.0 dB, Surround Mix Level: -3.0 dB
5 of 4009 video frames found with errors.
4 of 4179 audio frames found with errors.
254114 corrupted video bytes in file.
1.901900 seconds of video timestamp gaps.
1.920000 seconds of audio timestamp gaps.
post #750 of 1962
Couple of things I notice about your m2r log:

Quote:


1920 x 1080, 29.97 fps (26.84 fps Telecine), 38.81 Mbps (15.65 Mbps Average)

What program are you using to record and what muxer is it using? The 38.81 Mbps tells me that it is not filtering the program but sending the entire QAM stream and then dumping one of the programs from the stream. This is causing you to use more bandwith than necessary. You can make sure this is not the problem by setting "hdhomerun_config.exe FFFFFFFF set /tuner0/program 0" before the save command. That way you will save the entire stream and can see if you get errors. Then set to a specific program and save to see if it eliminates the errors.

The 26.84 fps Telecine tells me that you are remuxing to a program stream, this could be the cause of your errors. If you have a TS Mux option in your program, I would try that.
New Posts  All Forums:Forum Nav:
  Return Home
  Back to Forum: Home Theater Computers
AVS › AVS Forum › Video Components › Home Theater Computers › HDHomeRun - Dual ATSC or QAM to Ethernet Box