While the HR2x does constantly maintain a buffer of up to 90 minutes, you're always at live as long as you're not watching in the buffer - as soon as you pause or rewind, you're in the buffer. But the HR2x buffer is nothing more than an exact recording of the signal being recieved by the box.
Record Question
Does the HR-21 or HR-22 record all of the time while you watch TV like TIVO?
TIVO creates a lag when compared to live TV and the picture is not as crisp.
TIVO creates a lag when compared to live TV and the picture is not as crisp.
1 - 10 of 10 Posts
Yes, you have a 90 minute buffer, until you change channels. That allows you to "replay" anything within that time window.sd72667 said:Does the HR-21 or HR-22 record all of the time while you watch TV like TIVO?
TIVO creates a lag when compared to live TV and the picture is not as crisp.
The reason that you are seeing a more crisp pic on D* hardware than you had with TIVO is the recent changeover to the MPEG4 compression of the signal and decoding of the picture.
Year ago, I had several Ultimate TV DVR’s and a couple of old Sony SAT-A3 standard receivers. The UTV’s were always delayed compared to the A3’s. In fact, the UTV’s were often not even in sync with each other. I have noticed, though, that all of my HR20’s stay in sync and are even in sync with my H20. I will admit that sometimes if I have paused or reversed live TV, that even after catching-up, the HR20 doesn’t quite get back in sync with other units that remained live.
Thanks guys for the replies.
To clarify, ABSOLUTELY NOTHING is live from a DVR. Everything you see, including the buffer, recordings, and "live" viewing, is recorded to the HDD and then played back from the HDD before you ever see it. That is exactly WHY there is a lag, compared to a non-DVR IRD receiver such as the H20.sd72667 said:Does the HR-21 or HR-22 record all of the time while you watch TV like TIVO?
TIVO creates a lag when compared to live TV and the picture is not as crisp.
If we think about this for a minute it becomes obvious why they are required to do things that way. There would be no other way to perform trick play. You can't actually pause, rewind, or FFW a truly "live" signal. But you can make it appear that way if you write it to the HDD first and read it back from the HDD, which takes a second or so, and simulates live viewing.
This is not technically true.TomCat said:To clarify, ABSOLUTELY NOTHING is live from a DVR. Everything you see, including the buffer, recordings, and "live" viewing, is recorded to the HDD and then played back from the HDD before you ever see it. That is exactly WHY there is a lag, compared to a non-DVR IRD receiver such as the H20.
If we think about this for a minute it becomes obvious why they are required to do things that way. There would be no other way to perform trick play. You can't actually pause, rewind, or FFW a truly "live" signal. But you can make it appear that way if you write it to the HDD first and read it back from the HDD, which takes a second or so, and simulates live viewing.
I have any H20 and an HR20. THey are both in sync if I change the channel directly and do not rewind or pause. This because HR series record the raw MPEG2/4 stream directly from the sats. As soon as you pause, even if you fast forward to "Live" you are still a hair behind the H series.
But DirecTV, by the very nature of satellite technology, is always behind OTA, which would be considered truly "Live". Even watching OTA on the HR20, I am ahead of the H20. So the buffer time of the DVR is still less than the transmission time from earth to sat to earth again.
So to answer the OP's question, yes everything is both buffered and real-time. As far as real-time with satellites go.
I'm not sure if this is correct, someone please correct me if I am wrong. I believe the Tivo decoded the stream before recording/buffering it, while the Rxx and HRxx series record the undecoded stream and decode on playback. That could account for the difference in observable picture quality that you noticed.
Carl
Carl
Hrm, thats a good thought carl. That seems logical.
The Tivos definetly had a good amount of lag even on live. But the PQ should be the same no matter what...the advantage of DVRs with integrated satellite tuners is that they record the data stream and dont have to redo the encoding another time like standalone DVRs do.
The Tivos definetly had a good amount of lag even on live. But the PQ should be the same no matter what...the advantage of DVRs with integrated satellite tuners is that they record the data stream and dont have to redo the encoding another time like standalone DVRs do.
"Buffering" implies recording to a HDD. "Decoding" implies removing compression and restoring the signal to what it was before being compressed. That would mean the signals would expand to 1.458 Gb/s, which is the state they are in as they travel over HDMI. It doesn't take much math ability to see that this would reduce the record time on a 320 GB HDD to about a half hour. The program streams are recorded as they are received, or at least after demodulation and demux, which means they are still in MPEG format, and this is specifically to take advantage of the smaller file size. MPEG decoding is the very last step inside the DVR just before either formatting to the HDMI protocol or conversion to component analog.carl6 said:I'm not sure if this is correct, someone please correct me if I am wrong. I believe the Tivo decoded the stream before recording/buffering it, while the Rxx and HRxx series record the undecoded stream and decode on playback. That could account for the difference in observable picture quality that you noticed.
Carl
That is the very definition of a "bit-bucket" recorder as used by DBS, and is the same way it has been done since the first DTivos and DISH 501s. Since the decoding does not happen until after the signal is read from the HDD and no other manipulation is done to the video itself, bit-bucket recorders typically have no ability to affect PQ either pro or con, as that is locked in until decode, assuming the bit level during transport is high enough.
There are many things that affect the delay, and it is not always either predictable or comparable in the absence of knowing what all of them are and how much each contributes. You can't even accurately compare identical DBS systems side by side just because the decoding in one might take longer than in the other on occasion, and unpredictably so. I have had two DISH STBs (not PVRs) sitting side by side on the same channel at the same time, and one could be a second and a half more delayed than the other. Change the channel back and forth, and the early one might even become the late one. Surprising, yet true. While there are a lot of delays that can accumulate between the source, the backhaul, the uplink, etc. in DBS, this one proves how elastic and unpredictable the delay in decoding itself can be.
We know that there is about a 1/4 second delay just in the 46,000 mile trip a sat signal makes from uplink to TVRO, and that doesn't change because it is based on the speed of light and velocity of propagation, which are virtually constant. There is probably a predictable amount of delay in MPEG-2 encoding, a bit more in MPEG-4, but decoding is not really that predictable. MPEG decoding is pretty sophisticated and is also somewhat elastic, which is also why lipsync can creep in (as audio is more time-rigid).
There is delay in both analog TV OTA and DTV OTA, and of course there is more in DTV because of the digital processing and encoding. But if I compare my HR20 OTA to a HDTV tuner OTA, there is always AT LEAST 3/4 of a second more delay, which can probably be accounted for in the fact that it writes to the HDD and reads from the HDD before you ever see the video.
That said, Wisegoat may have a point. While the model for DVRs has always been to write/read first, it is technically possible to bypass that process on initial channel acquisition and immediately switch to the HDD on pause, FF (which of course doesn't work until you RW or pause), or RW. There had never been a reason to do that in the past, at least until MPEG-4, when channel acquisition time became a factor.
It could very well be that the longer acquisition time of MPEG-4 coupled with the added delay of a read/write was unacceptable to the DTV engineers, as there is a point where customers would find this annoying. If they could cleverly avoid the read/write time, as Wisegoat implies by skipping read/write until trick play, that would shorten the total channel-change time and improve the situation and actually let them use fewer I frames and compress even more efficiently.
So it's a plausible theory even if a little impractical, I just see no evidence of that being the case.
1 - 10 of 10 Posts
- This is an older thread, you may not receive a response, and could be reviving an old thread. Please consider creating a new thread.
DBSTalk Forum
A forum community dedicated to digital bit streaming enthusiasts. Come join the discussion about programming, content, and reception, home theaters, displays, models, styles, satellites, reviews, accessories, classifieds, and more!
Full Forum Listing
Recommended Communities
