1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.

I Threw The P.o.s. In The Trash.

Discussion in 'DIRECTV HD DVR/Receiver Discussion' started by WANDERER, Oct 4, 2006.

Thread Status:
Not open for further replies.
  1. bigviking

    bigviking AllStar

    66
    0
    Sep 20, 2006
    I agree that it sounds very unlikely that they did not ever see this issue in testing, with one possible exception ...

    If what they are struggling with here is the very common (and often very difficult to resolve) problem of memory allocation and overwrite errors, then I can definately see that their testing may not have flushed this problem out.

    From what I have been hearing about the sometimes flakey behavior, my bet is that this is exactly what they are dealing with. Errors of this nature are very tough to find, and re-produce. In fact, they don't make applications behave in any consistant manner what so ever. You could run the same exact code the same way a thousand times in a row without a problem, and the next time that you run it the problem could occur.

    I don't know what their programming environment is here, but if it is C or C++ my money is that they are still dealing with a memory over-run error rather than some basic application logic error. It could be a simple as a single improperly sized malloc call, an un-terminated string, or a slew of other things. If this is the case, I can see how their testing hasn't flushed it out.
     
  2. matto

    matto Banned User

    686
    0
    Sep 1, 2006
    Doing only functional and no exhaustive or regression tests would be unacceptable.

    Also, judging by the number of people who see problems on this forum, which is certainly a small subset of total users, even basic functional test coverage should have caught this.

    What I suspect is that this has been a known problem from the get-go, and engineering has not been able to resolve it (which is pretty pathetic). So for some reason, the decision is made to ship versions where the bug has not been resolved. Maybe the versions they're shipping address other bugs they consider more critical.
     
  3. hasan

    hasan Well-Known Member

    5,957
    54
    Sep 22, 2006
    Ogden, IA
    I posted this PRECISE theory several days ago, that is why I included the BTW comment...I have this uneasy suspicion that some of what we are seeing is MPEG-4 related (and I don't mean just watching an MPEG-4 channel, I mean if MPEG-4 is even presented to the box (channel surfing, etc)).

    I believe Earl does have MPEG-4, and since I thought that was the case (and my idea was a completely unsupported theory anyway), I dropped any pursuit of my comment.

    My contention from the beginning, reading the similarity (yet borderline chaotic nature at times) of so many issues that people are having was that there are "timing" issues in the code. These would show up predictably in some places, and randomly in others. I've seen it many times before with other software, especially during early portions of their development cycle.
     
  4. bigviking

    bigviking AllStar

    66
    0
    Sep 20, 2006
    I'm really not making excuses for the software bugs here, I'm just presenting what in my opinion is the most likey cause of the instability issues.

    With a difficult to find overwrite error, it really does just become a problem of statistical probability. They could have tested all of the scenarios without problems, and still had a bug like this pop up among a much larger group of production users.

    This is the very reason why I suggested a more automated and exhaustive testing process with very little user intervention in an earlier post today.
     
  5. matto

    matto Banned User

    686
    0
    Sep 1, 2006
    catching these problems is a lot easier when your developers write correct code to begin with. not catching buffer overflows in a closed system is an amateur mistake.
     
  6. WANDERER

    WANDERER Banned User

    231
    0
    Sep 27, 2006
    Verizon FIOS
     
  7. bigviking

    bigviking AllStar

    66
    0
    Sep 20, 2006
    I agree, actually it is a whole lot easier to catch if the code was correct to begin with because there wouldn't be anything to catch.
     
  8. matto

    matto Banned User

    686
    0
    Sep 1, 2006
    it easier to not worry about testing every oppertunity for bounds checking when your developers do it as a part of their coding guidelines.
     
  9. jclark

    jclark DBSTalk Club Member

    105
    0
    Oct 4, 2006
    If that is the case, I think that all of the QA people that I have worked with would have been fired at some point or another. Critical faults can show up because of data related issues or sequence of events usually because of a remembered state. It is very hard to catch these doing manual or automated testing because your test cases have to cover every single combination of functions that could possibly happen.

    But, I worked for a company that I think has the same approach to software development as D*. Their idea was to get a usable product to market. It didn't have to be perfect or bugless, but functional. Then they would work to refine it.
     
  10. matto

    matto Banned User

    686
    0
    Sep 1, 2006
    You said it, not me. :)
     
  11. bigviking

    bigviking AllStar

    66
    0
    Sep 20, 2006
    I agree, but if this is written in C or C++ the potential issues go far beyond simple bounds checking. I don't suspect that the issue is this simple.

    It could be that they have a bunch of java jocks that aren't use to the potential pitfalls of writing code in C or C++, as in java you can't cause a memory overwrite error simply by copying one string to another when the source string wasn't properly terminated.
     
  12. WANDERER

    WANDERER Banned User

    231
    0
    Sep 27, 2006
    Oh yes - strange combinations of events. Like hitting play or record! :)
     
  13. jclark

    jclark DBSTalk Club Member

    105
    0
    Oct 4, 2006
    Exactly! LOL! No, something a little more complicated than that. I did find a bug in our product(of course not my bug) that if you did something in function 1, it set a state variable that didn't reset. Then when you entered into function 2 (totally unrelated to function 1) nothing would work. I am just saying that it happens sometimes.

    Also, I just got my HR20 this past Sunday and from reading the boards I new that it was a work in progress. I guess that is why it doesn't me bother me. But if I was a normal consumer that bought this and saw that some of the functions mentioned in the manual and in the specs weren't working yet(OTA Tuner for one), I might be a little upset.
     
Thread Status:
Not open for further replies.

Share This Page