DBSTalk Forum banner
Status
Not open for further replies.
1 - 17 of 17 Posts

·
Legend
Joined
·
116 Posts
Discussion Starter · #1 ·
I've had an HR20 for just 3 days. I'm generally very pleased with the unit. Having used a 10-250 for the past year, I find they compare favorably in most operations.

Last night I suffered my first freeze while watching a live program. The picture froze during a commercial while the sound continued. After pressing every button on the remote and face of the HR20 I did a red button reset. Everything is now working normally again.

My experience last night and the number of posts concerning problems here on this forum, got me to wondering why people are experiencing so many crashes of the software on this unit. I understand that any new operating system will have bugs in it, but what is it about the underlying software kernel that allows so many system freezes. I have two Mac computers which I've not had to reset in at least three years. However, I understand that Windows users have frequent system freezes.

My question is directed to the considerable number of computer programmers like Earl who post to this forum. Is the operating system that DTV engineers are using ever going to allow for a crash-free HR20 or will occasional freezes be the norm for the unit and something we will just have to live with?
 

·
Lifetime Achiever
Joined
·
30,092 Posts
All I can say, is that they are not happy with the extent that the unit does hang and freeze... And yes... hopefully they will correct the issues, and get the unit to the point that it would be considered "crash-free" with in relative terms for such a dvice.

Occasional freezes... will hopefully be on terms of once or twice a year, if even that.
 

·
Lifetime Achiever
Joined
·
30,092 Posts
jtm said:
Thanks for the reply Earl. Can you tell me if the are using Unix or Linux as the basis for the software?
Sorry, don't know for sure what is being used under the hood.
 

·
Hall Of Fame
Joined
·
1,359 Posts
It's kind of a shame and the protracted instability issues will hang around D*'s neck like an albatross for a long time.

I mean, people still remark derisively about the "blue screen of death" relative to Microsoft Windows even though it no longer exists and hasn't for quite a while now.

I know...I'm repeating myself...but D* really did themselves and their previously first-rate reputation a great disservice by going to market with a product that they knew had lots of problems. It clearly says "we don't care a whole lot about our subscribers". Locking you into a 2-year commitment to get a buggy box only reinforces that negative perception. It kind of implies they know you might bail once it starts flaking out so they bettier nail you down. And let's charge a big upfront lease fee to to really cover our posteriors too.

It will be a long time before they live it down, even after they fix the stability issues. The HR20 is stigmatized and that can't be undone. It may take a next generation DTV+DVR to actually make it go away. That's a sad commentary on a unit less than 6 months old.

Too bad. I used to pimp D* to anyone who would listen as the the standard other providers should aspire to. No more.

This and the whole "leasing" thing has left me with a bad taste. Sunday Ticket is the only thing keeping me hanging on at this point.
 

·
Legend
Joined
·
116 Posts
Discussion Starter · #6 ·
HarleyD said:
Too bad. I used to pimp D* to anyone who would listen as the the standard other providers should aspire to. No more.

This and the whole "leasing" thing has left me with a bad taste. Sunday Ticket is the only thing keeping me hanging on at this point.
I still like D* a lot and continue to recommend it to friends. I just make sure they understand the potiential annoying problems.

What I'm still try to understand is: what is there about this unit that is so different from other consumer products that just work right out of the box. D* is not new to this business and supposedly the HR20 is based on a dvr that was already in use in Europe. Did the same problems occur there?
 

·
The Shadow Knows!
Joined
·
37,060 Posts
jtm said:
Thanks for the reply Earl. Can you tell me if the are using Unix or Linux as the basis for the software?
I don't remember where I read it but somewhere I read it was GNU.
 

·
Beware the Attack Basset
Joined
·
25,427 Posts
HarleyD said:
I mean, people still remark derisively about the "blue screen of death" relative to Microsoft Windows even though it no longer exists and hasn't for quite a while now.
Changing the color from blue to black didn't make the problem go away. There are still situations where a fully patched Windows XP will need a hard reset. This is similar to claims that the Macintosh never crashes.

My guess is that they aren't using *nix. That road is too well traveled and they would have to be looking over their shoulder at the Linux DVR and TiVo hacker communities.
 

·
Beware the Attack Basset
Joined
·
25,427 Posts
lamontcranston said:
I don't remember where I read it but somewhere I read it was GNU.
The receiver manuals often refer to the GPL, but only in the context of TiVo software.
 

·
Beware the Attack Basset
Joined
·
25,427 Posts
jtm said:
What I'm still try to understand is: what is there about this unit that is so different from other consumer products that just work right out of the box.
The difference is that most other products are allowed to complete the development cycle before they are released.
D* is not new to this business and supposedly the HR20 is based on a dvr that was already in use in Europe. Did the same problems occur there?
DirecTV is indeed new to the business of designing and building DVRs without the support of a major consumer electronics marketing company (Sony, Toshiba, RCA, Philips). The NDS receivers are similarly afflicted, probably not because they are derived from them, but rather they were released well before they were ready.
 

·
Icon
Joined
·
526 Posts
jtm said:
My question is directed to the considerable number of computer programmers like Earl who post to this forum. Is the operating system that DTV engineers are using ever going to allow for a crash-free HR20 or will occasional freezes be the norm for the unit and something we will just have to live with?
I wouldn't worry too much about the operating system. There may be certain features that need to be avoided to achieve stability but every operating system is designed to run for months without crashing. I've personally seen that sort of stability out of Windows 3.1, Windows 95, Windows NT, Windows XP, and Windows CE.

The problem is reproducing problems, and dealing with new problems when a lot of time is still being burnt on old problems. I recorded a basketball game on Weds night that just showed up as black when played back. After a reset it wouldn't play. But after some futzing around it did! On Thurs night I recorded another game and it worked fine. How can they reproduce that? If they had some means to access information from the box itself they might be able to get to the bottom of it.

In my opinion the box is way too sensitive to what's coming over the line and through the guide. Once it's recording, there shouldn't be anything that happens to convince it to stop, or not play the stream back. Dealing with unexpected data requires a lot of rigorous programming that is best done upfront.

Something I'd like to see is a much more dogged approach to handling something I told it to record explicitly. Basically I'd like to see it NEVER remove a recording that's been manually requested. If the guide data says the program has moved then it should probably adjust the parameters. But I've seen numerous times I've selected a recording in advance, and then as it comes closer to the air time it inexplicably disapears. And if it's already recording something it should never stop just because the guide data glitched, if anything it should flag it somehow and keep on going.

They desperatly need a screen to report and help resolve issues. Every program that's been re-scheduled or removed due to a conflict should be displayed. There should be an indicator on the screen whenever an entry is added to that list.
 

·
Lifetime Achiever
Joined
·
21,332 Posts
Lots of questions, infinite guesses. My theory is that 2 years ago, someone challenged the software team to build DVRs by Jan. 2006, and the team said "sure, no problem!" So the Tivo line was cancelled, development was underway, a common user interface was going to finally happen, all was good.

But developing consumer electronics is not easy, and not like writing any old application. The QA cycles must be much, much more thorough. And embedded programming of hardware devices is also much trickier, normal debugging techniques only apply to a few parts (the UI); the rest take specific skills and tricks to reproduce. find, and then solve. So the project became vastly delayed, the Tivos were out of stock, it is the Christmas of HDTV, and Directv had an ugly choice: ship bugs or ship nothing.

As to how do so many defects creep in, my experience indicates that the programmers all followed similar techniques, normally a good practice for software development. But when that set of techniques, normally good for applications (or at least marginally good enough) fails in an embedded device, a company will find themselves in a disasterous situation.

What should be done? Scour the code base for every instance where a poor technique for embedded programming was used and rewrite. And that is expensive and time consuming. But it is the best way. Sometimes programs can be written to search for the most common problems.

Until then, we all live with what we got.

Now, a very intriguing question remains with my theories. Why do some people have lots of problems and others have very few? Especially when we here compare usage patterns and find that not to be very telling!

My pitifully weak answer is something to do with timing and an individual's environment. But I find that unsatisfying.

Anyway, have a very Merry Christmas!
Tom
 

·
RBR Hitit tillit bricksit
Joined
·
266 Posts
I think they need to do a several things to gain some reliability:

1. Stop all work on future non critical features (OTA WAS CRITICAL!), concentrate those resources on the core features.

2. Stop trying to fix everything in one big release. Increase the quantity of releases by fixing a few things at a time.

3. Fix the major core functions first. Like the unwatchable bug.
 

·
Legend
Joined
·
116 Posts
Discussion Starter · #14 ·
tibber said:
Now, a very intriguing question remains with my theories. Why do some people have lots of problems and others have very few? Especially when we here compare usage patterns and find that not to be very telling!

My pitifully weak answer is something to do with timing and an individual's environment. But I find that unsatisfying.

Anyway, have a very Merry Christmas!
Tom
And maybe it's just God saying:

"I don't know Clyde. Sometimes you just piss me off!"
 

·
DBSTalk Club Member
Joined
·
251 Posts
Brantel said:
2. Stop trying to fix everything in one big release. Increase the quantity of releases by fixing a few things at a time.
That's easy to say when you're not a software developer. Oftentimes, fixing one problem will fix a lot of others. Or cause new problems. Or not solve the problem you thought it would solve... A lot of that confusion can be mitigated by writing good code to begin with, but it's still difficult.

Besides, you have no proof that they've tried to fix everything in "one big release." Correct me if I'm wrong, but the release notes only ever say "stability improvements" or something generic like that.
 

·
Lifetime Achiever
Joined
·
30,092 Posts
Brantel said:
2. Stop trying to fix everything in one big release. Increase the quantity of releases by fixing a few things at a time.
They are hardley trying to fix everything in one release.

But for a product like this... that when the updates go, they are the ENTIRE package, not just a file here or there or here..
You can't just release them as they are finished...

Or they will be pushing software updates every day... and that doesn't work in this enviornment (or really in any enviornment)
 

·
Registered
Joined
·
5,747 Posts
tibber said:
My pitifully weak answer is something to do with timing and an individual's environment. But I find that unsatisfying.
But none the less those variables still need to be kept in consideration. I don't think it's weak at all actually.
 
1 - 17 of 17 Posts
Status
Not open for further replies.
Top