[socal404]

I know this subject has been discussed on other threads many times, but my search has not come up with an answer to my question. I have (2) R22-100s w/HD and an HR24-200. The R22-100s are extremely slow, especially when I first turn them on in the morning. I've done the RAM clearing, and they are still slow. It is obvious that DTV can and has corrected other flaws in the past. Why can't they seem to fix this glitch? I would appreciate any useful solutions to this problem. Also does anyone know if DTV is working on this problem? Thanks.

 

[veryoldschool]

It's going to be hard to overcome hardware limitations.
The R22 simply has the least "horsepower" of all the DVRs.

 

[Richierich]

It's going to be hard to overcome hardware limitations.
The R22 simply has the least "horsepower" of all the DVRs.

+1.

They finally realized that the CPU and RAM weren't enough for all of the things they were trying to get the DVR to do so some just are Sluggish.

My HR24-500s are Very Fast!!!

 

[Halo]

They lack the skill. That was obvious to me years ago. Even 6 year old tech like the HR-20 is still remarkably fast. It is easily fast enough to handle all the duties of a HD-DVR (reliable and responsive) if properly designed.

Unless you've spent some time writing code for embedded systems it may be difficult to understand how much can be done in just 1 second. Hundreds of millions of instructions per second. 1 second is an eternity to a modern CPU. Especially with decoding duties handled by hardware there is absolutely no excuse for the user interface to ever become unresponsive.

Blaming NVRAM or guide data for slowness is pathetic. If any of those things slow down you system then you didn't write it correctly. But yeah, just blame the hardware. I design both. The hardware is extremely capable.

Six years of development and they still don't have a handle on their hardware. They still have obvious bugs and incredible slowdowns. And they still draw a paycheck.

 

[veryoldschool]

They lack the skill. That was obvious to me years ago. Even 6 year old tech like the HR-20 is still remarkably fast. It is easily fast enough to handle all the duties of a HD-DVR (reliable and responsive) if properly designed.

Unless you've spent some time writing code for embedded systems it may be difficult to understand how much can be done in just 1 second. Hundreds of millions of instructions per second. 1 second is an eternity to a modern CPU. Especially with decoding duties handled by hardware there is absolutely no excuse for the user interface to ever become unresponsive.

Blaming NVRAM or guide data for slowness is pathetic. If any of those things slow down you system then you didn't write it correctly. But yeah, just blame the hardware. I design both. The hardware is extremely capable.

Six years of development and they still don't have a handle on their hardware. They still have obvious bugs and incredible slowdowns. And they still draw a paycheck.

Maybe you should apply for a job.
The HR20 has a better chipset than the HR21-23. I've had both, and running the same firmware, the HR21 is a tad slower.
Not sure why, and it isn't "always the cure", but clearing the NVRAM has helped several/many times.

I once heard how much storage they had for the firmware and it was something incredibly small.

 

[bpratt]

They lack the skill. That was obvious to me years ago. Even 6 year old tech like the HR-20 is still remarkably fast. It is easily fast enough to handle all the duties of a HD-DVR (reliable and responsive) if properly designed.

Unless you've spent some time writing code for embedded systems it may be difficult to understand how much can be done in just 1 second. Hundreds of millions of instructions per second. 1 second is an eternity to a modern CPU. Especially with decoding duties handled by hardware there is absolutely no excuse for the user interface to ever become unresponsive.

Blaming NVRAM or guide data for slowness is pathetic. If any of those things slow down you system then you didn't write it correctly. But yeah, just blame the hardware. I design both. The hardware is extremely capable.

Six years of development and they still don't have a handle on their hardware. They still have obvious bugs and incredible slowdowns. And they still draw a paycheck.

I have to agree with Halo. My HR10-250 is much faster than my HR21-700s which have a processor that is 4 or 5 times faster than the HR10. The code for the HR10 was written by TiVo. They knew what they were doing.

 

[veryoldschool]

I have to agree with Halo. My HR10-250 is much faster than my HR21-700s which have a processor that is 4 or 5 times faster than the HR10. The code for the HR10 was written by TiVo. They knew what they were doing.

I'm not going to disagree about TiVo's ability to code.
It would be more "apples to apples" to compare the THR22 to the HR21, than use an MPEG-2 receiver to compare to an MPEG-4 receiver, since this isn't "apples to apples".

 

[billsharpe]

After months of frustration over my slow HR20-700, my solution was to switch providers.

The NVRAM reset helped temporarily, but not much.

 

[keith_benedict]

I'm not going to disagree about TiVo's ability to code.
It would be more "apples to apples" to compare the THR22 to the HR21, than use an MPEG-2 receiver to compare to an MPEG-4 receiver, since this isn't "apples to apples".

I disagree. Isn't there an ASIC that handles the MPEG decoding? The drawing of the guide and other menus in the UI should be handled separately from the MPEG decoding.

 

[harsh]

I disagree. Isn't there an ASIC that handles the MPEG decoding? The drawing of the guide and other menus in the UI should be handled separately from the MPEG decoding.

Most everything you see on the screen or hear is handled by hardware. What's left over the is database functions and that's something that still begs for improvement.

 

[veryoldschool]

I disagree. Isn't there an ASIC that handles the MPEG decoding? The drawing of the guide and other menus in the UI should be handled separately from the MPEG decoding.

MPEG-4 requires more memory and processing than MPEG-2.
You can see this with on your computer with video chips that handle MPEG-4 decoding which off loads the CPU's load.

Many years ago I played with an HD OTA tuner card, which worked with I think my 800 MHz Pentium III & an ATI 9600.
Moving to DirecTV2PC, I found I needed more of just about everything.
I had a 3 GHz Pentium 4 HT and nVidia 6600, which worked fine for MPEG-2 HD, but 1080 HD MPEG-4 wouldn't work.
720p MPEG-4 would bury the CPU at 100%, but played.
Overclocking the CPU to above 3.3 GHz would just get it to squeak by, but was marginal for 1080 MPEG-4.
Changing to an ATI 3650 [on board MPEG-4] let me "underclock" the CPU down to below 1.7 GHz and still have plenty of CPU left to use.

 

[Supramom2000]

For whatever reason, my two R22's are faster than my HR23.

 

[veryoldschool]

For whatever reason, my two R22's are faster than my HR23.

I think there is some merit to which design you have [the maker's -xxx], though they do use the same core chipsets.

 

[JonW]

They lack the skill. That was obvious to me years ago. Even 6 year old tech like the HR-20 is still remarkably fast. It is easily fast enough to handle all the duties of a HD-DVR (reliable and responsive) if properly designed.

Unless you've spent some time writing code for embedded systems it may be difficult to understand how much can be done in just 1 second. Hundreds of millions of instructions per second. 1 second is an eternity to a modern CPU. Especially with decoding duties handled by hardware there is absolutely no excuse for the user interface to ever become unresponsive.

Blaming NVRAM or guide data for slowness is pathetic. If any of those things slow down you system then you didn't write it correctly. But yeah, just blame the hardware. I design both. The hardware is extremely capable.

Six years of development and they still don't have a handle on their hardware. They still have obvious bugs and incredible slowdowns. And they still draw a paycheck.

I agree, alas it's always easier to pile on new code than it is to optimize or re-design existing code; and companies that don't derive their revenue directly from s/w may see it as little more than a necessary evil/marketing device.

 

[TomCat]

dupe deleted

 

[TomCat]

They lack the skill...

I think that about sums it up.

There is support for this argument: If you have experience with DISH DVRs, they are generally all pretty snappy. Of course the trade-off there is they are also unreliable, and the DISH service is somewhat inferior in many ways (there are still top-market stations that are not in HD LIL, for one thing). So their coders have the skill to provide the speed, but lack the skill to make their DVRs very reliable. And all DVRs pretty much run on the same garden-variety off-the-shelf CPUs and decoder chips from the same sources, so that can't be used as any excuse.

I have to agree with Halo. My HR10-250 is much faster than my HR21-700s which have a processor that is 4 or 5 times faster than the HR10. The code for the HR10 was written by TiVo. They knew what they were doing.

Well, yes, in some ways it is faster, and Tivo made efforts to speed things up in some of their up revs as well, but at the expense of reliability, so maybe no coder has the chops to do both.

And the HR10, much-beloved as it is, is not really all that fast in many areas, although I agree it is faster in GUI response for many of the most frequent tasks. I just deleted a SP on my one remaining HR10 yesterday (out of a total of only 9 SPs), and it took over 4 minutes to recover. More than 4 entire minutes of the "please wait" clockface logo staring back at me. It also takes 30-40 seconds to display the main GUI screen when I first access it each day, but this is likely due to the fact that it has to first parse failed mothership connection attempts for the last 1800 days.

 

[peano]

There is support for this argument: If you have experience with DISH DVRs, they are generally all pretty snappy. Of course the trade-off there is they are also unreliable....

I have owned six or seven different Dish models and all have worked flawlessly. I cannot say that about my HR22.

I definitely agree that DIRECTV's code writers are poor at best.

 

[Supramom2000]

I think there is some merit to which design you have [the maker's -xxx], though they do use the same core chipsets.

I have both an R22-100 and an R22-200. So far, both are faster than the HR23.

I'm not really sure why.

 

[Podkayne]

My HR 20-100 is still double pig-dog slow...done all of the usual stuff. I'm sure they're working on a fix. There has to be a huge installed base of these things and there's no way they can afford to replace them.

 

[veryoldschool]

My HR 20-100 is still double pig-dog slow...done all of the usual stuff. I'm sure they're working on a fix. There has to be a huge installed base of these things and there's no way they can afford to replace them.

I once heard a rumor that they wanted to dump them with MRV/DECA, [one of the reasons being the strange configuration needed], but it was repeatedly "overruled", so we're still stuck with them.