Separate names with a comma.
Discussion in 'DIRECTV HD DVR/Receiver Discussion' started by socal404, Mar 4, 2012.
It was the broadcaster's error?
I had none of these problems on 59e, now that both of my HR21-700s are on 59f, I get a few video breakups or pixilation every day. I also am getting a few audio glitches also, where a few words are not understandable. If I rewind and then replay the problem areas, the problem still exists.
While I don't know the channels/shows that you're watching, this is a sign of a problem in the feed. Maybe it's from the SAT, or maybe there is a problem with the reception, but if replaying it has it "still exist", this is a sign it was recorded that way.
Now if you replayed them and they didn't repeat, that would be another issue and may be related [more] to a software problem.
Both the audio and video?
About 30% of the time when there is a vidio glitch the audio also has a problem.
Well, it's good (or actually sad) to see I'm not the only one wondering what the hell happened to my HR23/700.
When the new GUI came out, I was in hog heaven, as the guide was considerably faster than the old POS. But... it's been getting slower... and slower... and is now back to the sluggish slow response I remember.
I've optimized the settings (native only, scroll settings, etc.), cleared the cache, done a reset.
Nope. Still a painful experience. Even using the PREV button to bounce back and forth between 2 channels is insanely slow.
Maybe I'm just fed up, but it seems just as miserable as the old GUI was in terms of system response to remote actions.
They need to fix the sh*t. They can keep all the extra crap like Pandora and just make the damned thing work at a reasonable speed.
It makes you wonder how many layers of bloated programming there are stacked on top of one another... but I thought this new GUI was rebuilt from scratch to be leaner?
I agree with you about the extra crap, but D* is in a very competitive market. They cannot market "the best working HD DVR". They can market the most HD channels, Pandora, Nomad, MRV, and YouTube. I have been a D* customer since 1994, and D* has never gotten it 100%. What they have going for them, is their competition does not have it either. Best wishes!
Think those 21-700s might be wearing out? I got rid of mine awhile ago. Very dependable DVRs, but they got so slow we couldn't deal with them anymore.
Have you flushed the Guide? That usually helps me when mine slow down. I gotta admit I'm getting tired of this creeping slowness too. I "woke up" a couple of 20-700s that I only use as servers the other day and I couldn't believe how slow they were. I just did what I had to do and put them back in "Server Heaven" where the slowness isn't apparent.
Gotta have patience, the next couple NRs ought to address these issues.
OK, lots of expertise here but almost exclusively dedicated to describing the problem. What am I to DO about my pathetically slow R22?
I've learned from experience that if I call and complain and they replace it with a better one I run the risk of having a year added to my DTV commitment. Might be worth it.
Would a good quality, large capacity external HD help? I'll welcome suggestions as to whose and how big. My internal is 50% full.
I've tried the tips & tricks in settings, mem clearing etc.
All I can say is be patient.
We've been hearing that for almost 6 years now. My patience wore out.
Having coded microcontrollers as a hobby, I can appreciate the challenges of implementation and optimization the DTV programmers face. Working with a limited code and RAM space, and working with a real time operating system is a challenge. I would imagine getting two processors, a CPU and a DSP, to run well together is also tricky. It has the advantage that at least you know what hardware your code will be running on to the smallest detail, vs computer programming which has to be as generalized as possible.
But, the bottom line is that waiting 20-30 seconds just to change a channel is inexcusable and extremely annoying.
I'm not talking about fragmentation, dissimilar data naturally gets spread all over the disk - and this includes things like the disk structures themselves.
Recording to disk and play back from disk are no doubt given the highest priority, which means other requests like piecing together the play list or guide information will take a back seat. This goes for the disk, and the CPU. There is a point that one or the other will start thrashing.
Anyway, without knowing exactly how data is stored on the disk, this is all just speculation, but in my experience expecting s/w programmers to take the most efficient approach is a mistake in this day and age as there's an expectation that code can just be thrown together and be made to work - because as you say the disk/CPU are so fast and RAM is cheap. Well? We can see it with our own eyes. These systems can be brought to their knees. Optimization is becoming a lost art.
Even my 4 GHz + 4GB PC can start running slower than a 286 if I manage to run it nearly out of RAM and resources.
I'm not sure this is a reasonable comparison. Where microcontrollers often have memory measured in the kilobytes, I'm pretty sure the DIRECTV DVRs have memory measured in the megabytes.
Microcontrollers don't usually have 300Mhz+ processors nor access to mass storage either.
How do you flush the guide?
Two resets within 30 mins does it.
Thank you. What does flushing the guide do?
There's an enormous range of capabilities in the embedded market, but it all costs money so if you put more power than you need in to a box, it's just going to cost more to manufacture, consume more power, require more cooling, etc.
And it's not really all that hard to blow through a megabyte these days :O
It will make your dvr faster for about a week...if you are lucky.