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.
"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.
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.