[ericmatz]

Hello everyone,

I now have the Vip 622 with the Dish HD Silver package. I really like them; however, there are issues with the studdering and closed captioned that I mentioned in the forums. Now my question is this: Does Dish people review the forums from dbstalk.com? Are they reading them or the moderators and/or others from this site actually communicate with the Dish people? I am trying to understand why Dish is having such a hard tiime with the problems that we have. And it is taking so long for Dish to resolve some of the problems? I have been a customer of Dish Network for 12 years and will NOT change the providers. I feel that they need to work harder to resolve the problems. Thank you.

 

[Ron Barry]

Eric,

Ok.. Personal opinion here based hanging out here and from what I have been told from my experience talking to Dish Employees... .

I have seen both actually happening. Dish does look at these forums as they do others I am sure. I can't speak about other forums, but I believe that because we try and provide a constructive bash free as possible forum, Dish Engineers would be more inclined to wonder these halls (I have no positive evidence, just an opinion based on past experiences here).

There has been times where Dish Engineering has asked for the help of users on this board. Most recent being to take a Beta hit of L3.65 to see if it addressed the audio issues that users with L3.60 was seeing. I also remember a reboot issue with the shared view setting a few revs back that I believe was quickly identified and relayed back to engineering resulting in providing a duplication of steps that is big when it comes to software debugging. So I do believe that we do help and that the feedback we provide is used by the Dish Engineering.

As for fixing problems we are seeing, Like I have always said the more information the better and we all use the boxes differently and we all have different configurations. It is good that people post experiences to give an overall view of how the 622 is performing, but it is even better when details are provided that might provide clues the engineers can use to duplicate the issues.

Debugging software related bugs like Crashes and audio loss is not usually a trivial matter. The more information the better and even with detailed field information the problem might be hard to reproduce. From my experiences, some bugs can take an hour to fix while others take 6 months. A good example of a tough bug that is floating around here is the jitter one. Not everyone sees it and it comes and goes. Very hard to reproduce and I am sure this one will be hard to squash.

Hopefully this answer your questions. To sum it up.... I believe this forum helps or I would not be spending my time here and I also know that software is more an art than a science and takes time to create a high quality piece of art.

 

[Mikey]

... I also know that software is more an art than a science and takes time to create a high quality piece of art.

If they're treating Software Engineering as an art, then that's the problem. It's a science, an engineering discipline. The standards exist, the interfaces are defined, the components are specified to tolerance. Requirements are specified, test cases are defined to execute all code steps, performance data is gathered using the proper equipment, and analzed for any discrepancies.

If their firmware doesn't work when it gets to the customer, then someone didn't do his job right. It's not an art, it's not magic, it's engineering. If the engineers can't cut it, get better engineers.

If this seems to be bashing, it is. Feel free to move this to the bashing forum.

 

[R_Childress]

As a software engineer myself, I will tell you that more than one oerson works on code. One person might be responsible for one feature while someone else is responsible for the other. Different people work on different modules of the firmware. It is difficult at best when you combine these and compile these together to predict the outcome. The best you can do is to test as thoroughlly as possible and then release the software, hoping you caught as many problems as possible and can fix the others as they pop up. It is like this everywhere.

 

[James Long]

We don't have a bashing forum.

The processes they are using are certainly scientific, but there is certainly a human element. It is easy to decide that something does or doesn't work when it is an issue of "if you do A, B should happen". But many of the issues discussed here are more complicated. Especially dealing with a userbase that varies in just what they do with their receivers.

Problems that pop up immediately are good too. The "when I press GUIDE on TV1 TV2 changes channel" type error (as a fictional example). Repeatable ... perhaps not logical, but they can look at the code and see the process followed by the receiver to come to that outcome.

Some of what E* is facing now is the "over time" type of errors. Everything works fine then suddenly it doesn't. Now they have to figure out what is different when the error occurred. Imagine an error that shows up when HD is buffered more than one hour in pause. How many people are going to find that error? If it shows up when HD is buffered more than 30 minutes it is more likely to be found as more people are likely to pause 30 minutes than an hour.

That is where the art comes in ... testing. Trying to do everything that a customer may end up doing with their receiver. And doing it in a way that if an error is noted they can figure out how to fix that error. Knowing exactly what to look for in each release isn't as scientific is one might think. Sure, if the engineer has been working on a code to make button Z purple when some condition occurs they can cause the condition and see if the button changes to purple. Trying to make the receiver "more stable" is trickier.

I don't write firmware for a living, but I know that sometimes the right answer to a problem isn't always what an exact scientific rendering would come up with.

Anyways, the more information we can give to those who DO write firmware for a living the better. When something fails try to note what was happening at that moment - try to recreate the failure - report in detail. Keep the emotions in check. That firmware engineer is probably wound up enough about his product not working right - he doesn't need to be bashed.

 

[Ron Barry]

If they're treating Software Engineering as an art, then that's the problem. It's a science, an engineering discipline. The standards exist, the interfaces are defined, the components are specified to tolerance. Requirements are specified, test cases are defined to execute all code steps, performance data is gathered using the proper equipment, and analzed for any discrepancies.

If their firmware doesn't work when it gets to the customer, then someone didn't do his job right. It's not an art, it's not magic, it's engineering. If the engineers can't cut it, get better engineers.

If this seems to be bashing, it is. Feel free to move this to the bashing forum.

Never said it magic but there is definitely a big creative component to the process in my opinion based on my 15+ years of Software Development I have had. My art comment was based on the fact that software is both a science and an art. art piece is the creative process that occurs from taking piece of paper like a specification and creating software to meet that specification.

Ok.. I have a lot more to say on this topic and to avoid rat holing as to what makes good software practices, I will avoid expanding my thoughts. If people want to discuss the topic of the challenges developing embedded software in a Dish like environment it should be taken up in the general areas.

Lets keep on topic here and lets not use this thread to start rock throwing towards the Dish engineers. I tried to addressed some of the challenges that the Dish engineers might be facing as they squash bugs.

One last clarification... My post was not saying that Dish Engineers see software development as an art so they don't use solid engineering practices and just paint away ... I personally believe that they do use solid engineering practices and I will leave it at that.