DBSTalk Forum banner
Status
Not open for further replies.

Why Can't Slow Receivers be Fixed?

60K views 445 replies 99 participants last post by  Stuart Sweet 
#1 ·
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.
 
#3 ·
veryoldschool said:
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!!! :)
 
#4 ·
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.
 
#5 ·
Halo said:
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.
 
#6 ·
Halo said:
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.
 
#7 ·
bpratt said:
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".
 
#9 ·
veryoldschool said:
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.
 
#10 ·
keith_benedict said:
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.
 
#11 ·
keith_benedict said:
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.
 
#14 ·
Halo said:
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.
 
#16 ·
Halo said:
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.

bpratt said:
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.
 
#17 ·
TomCat said:
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.
 
#18 ·
veryoldschool said:
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.
 
#20 ·
Podkayne said:
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.
 
#21 ·
To improve speed
Turn off Resolutions [Native Mode].
Turn off Scrolling Effects.
Disable ID
The remote's model ID sends remote information to receiver with each keystroke, narrowing options for remote-to-receiver programming.
Customers may need to disable Model ID if receiver is slow to respond to remote commands.
Press and hold Mute and Select until the green light flashes twice.
Enter 9-6-3 on numeric key pad.
The green light on remote should flash twice.
Press the Channel Down key.
 
#22 ·
I'm retired, so speed is not an issue. It would be nice if D* would get the bugs fixed before introducing another DVR like the HR34. Read through the DirecTV threads in DBSTALK, and you will soon realize that D* needs to direct their resources to perfecting their current hardware and software. Have a great day!
 
#23 ·
beforesixbeers said:
To improve speed
Turn off Resolutions [Native Mode].
Turn off Scrolling Effects.
Disable ID
The remote's model ID sends remote information to receiver with each keystroke, narrowing options for remote-to-receiver programming.
Customers may need to disable Model ID if receiver is slow to respond to remote commands.
Press and hold Mute and Select until the green light flashes twice.
Enter 9-6-3 on numeric key pad.
The green light on remote should flash twice.
Press the Channel Down key.
I'm sure all of these are good, but I've only ever turned off scrolling and leave all the other intact.
My old HR20-700s [from the early days where they were made in Mexico] were fine.
My HR21-200 [again the first run] was only about a half second slower than my HR20s.
Time has passed and now I only have the -500s.
 
#24 ·
You know, people have different opinions about what constitutes "slow". I'm not saying your DVR is fast, but to many people it may be acceptable. There are a lot of other factors too... The health of the hard drive, the quality of the signal, the compression used at the back haul facility... There are a lot of factors.
 
Status
Not open for further replies.
You have insufficient privileges to reply here.
Top