# How to Fix the 921



## welchwarlock (Jan 5, 2005)

I have been a professional Software Engineer for more than 20 years, and as is obvious to everyone, the 921 unit has major quality problems. I wonder what the root cause is? Perhaps it is poor leadership from the software team. Certainly there is poor test planning and execution. 

I wonder how they get this thing properly tested in England, without having Local HD channels, or direct view to all of dish's birds. In England, most people don't have large TVs or High Definition. The houses are smaller on average and don't support large TVs, and the Tax on TVs increases with the screen size. Nearly all of my coworkers here have High Def, and Big Screens, my counterparts in England do not.

It just does not seem practical to me. Someone in this forum suggested that all the engineers that work on this be forced to use it as their only source of TV programming. I agree, and would go a bit further.

I suggest that the entire Software team from England be transplanted Stateside until all the problems are resolved. I would also include 1 or 2 key hardware designers in the group as well. Move them into apartments, equip them with 921 receivers, and keep them here until all the bugs are fixed. Make them work 12 hour days, 7 days a week. Get it fixed.

I can't believe that Dish Network continues to let this product give them a black eye, and lets these problems go on for so long.

Regards,

Robert Cook

Dish 811
Dish 921
Voom


----------



## RAD (Aug 5, 2002)

If I remember correctly on a Charlie Chat, before the 921 was released, Charlie said he had one in his house. Now since the Denver area is OTA ATSC challanged I wonder how he, or any of the other E* folks in the area, had any realy experience with OTA digital?

And don't limit your question to only the 921, all recent, non basic (like the 311), have had QA issue upon release that takes number of months to correct, if then.


----------



## FrankD1 (Jul 14, 2002)

welchwarlock said:


> I have been a professional Software Engineer for more than 20 years, and as is obvious to everyone, the 921 unit has major quality problems. I wonder what the root cause is? Perhaps it is poor leadership from the software team. Certainly there is poor test planning and execution.
> 
> I wonder how they get this thing properly tested in England, without having Local HD channels, or direct view to all of dish's birds. In England, most people don't have large TVs or High Definition. The houses are smaller on average and don't support large TVs, and the Tax on TVs increases with the screen size. Nearly all of my coworkers here have High Def, and Big Screens, my counterparts in England do not.
> 
> ...


I've had the same thoughts about testing in the UK. While E* has plenty of people (Charlie included) in CO to test, it's the developers that need to be able to EXACTLY reproduce the environment in which bugs are occurring in order to fix them properly, and I just don't see how they can do that in the UK, where they can't see all the birds.


----------



## Mikey (Oct 26, 2004)

I agree this is a software QC issue. However, in this age of automation and remote control, physically transplanting software engineers isn't required to accomplish the desired result. What would be required is:

1. High speed internet
2. PC with 2GHz plus CPU
3. Remote control software for the PC
4. An HDTV video card for the PC
5. An in-circuit debugger
6. A 921 with the debugger inserted in place of the firmware

Repeat the above configuration for the 811/942/..., as required.

With this setup, a lab in Denver/LA/? could exist that has the proper OTA environment. The UK software engineers could make their changes remotely and control the equipment from their own office. Everybody still sleeps in their own beds at night.

Well, maybe not. There's still that issue of the big screen. Maybe someone can brainstorm a way around that too.


----------



## welchwarlock (Jan 5, 2005)

Mikey said:


> I agree this is a software QC issue. However, in this age of automation and remote control, physically transplanting software engineers isn't required to accomplish the desired result. What would be required is:
> 
> 1. High speed internet
> 2. PC with 2GHz plus CPU
> ...


Transplanting the engineers for a month or two makes them uncomfortable and motivated to get the job done so they can go back to their families. Also by transplanting them you can put one of the units in each of their rooms / apartments while they are stuck here...literally letting them sleep in the bed that they make....or enjoying the fruits of their labour. With the more than favorable exchange rates right now, there might even be less resistance to the plan than normal. You would also get more hours out of them.

If they are on standard UK work week, they are only putting in 35 a week. Strand them in the states working 12 a day until it gets fixed. I have worked 16 hour days for weeks at a time getting software fixed...based on the slow release rate of their fixes, I doubt they are burning the midnight oil...heck maybe there is only one poor sap working on it all by himself while they write the code for the 942!


----------



## Ron Barry (Dec 10, 2002)

welchwarlock said:


> Transplanting the engineers for a month or two makes them uncomfortable and motivated to get the job done so they can go back to their families. Also by transplanting them you can put one of the units in each of their rooms / apartments while they are stuck here...literally letting them sleep in the bed that they make....or enjoying the fruits of their labour. With the more than favorable exchange rates right now, there might even be less resistance to the plan than normal. You would also get more hours out of them.
> 
> If they are on standard UK work week, they are only putting in 35 a week. Strand them in the states working 12 a day until it gets fixed. I have worked 16 hour days for weeks at a time getting software fixed...based on the slow release rate of their fixes, I doubt they are burning the midnight oil...heck maybe there is only one poor sap working on it all by himself while they write the code for the 942!


Interesting suggestion, however, I think your suggestion would have an adverse effect and Yes i have worked 16 hour days for a month straight to fix a bug that was effecting a million customers. It is a work environment that is sure to kill teams moral if done for a long period of time.

1) This would result in uprouting a number of people with familes and most likely will not motivate people in any way you might think. It surely would not motivate me and in this type of abusive environment I would be looking tomorrow. Infact, if you want to have a flood of people resign, this is one way to do it. There are other positive means to motivate an engineer. This is not one of them and I am glad you are not my boss.

2) This plan would require a sufficient amount logistics to create an environment like this. This adds to the overhead and i am not sure if the benefits outway the results. Hard to say without doing an analysis.

I do share the same questions about how testing is down given the fact that England is on PAL and don't have the most likely don't have the same OTA scheme we do. This is also the same struggles that occur when moving development over to other out of the US locations. My personal thought was this was not a good idea in the first place and is the location attributed to the high defect count out the door.

I tend to agree with Mikey in that ther are other alternatives. We do remote development all the time, though it is

If we were to take all software developers and throw them into appartments away from their familas until bad software reaches an acceptable level there would be no apartments available.


----------



## welchwarlock (Jan 5, 2005)

Ron Barry said:


> Interesting suggestion, however, I think your suggestion would have an adverse effect and Yes i have worked 16 hour days for a month straight to fix a bug that was effecting a million customers. It is a work environment that is sure to kill teams moral if done for a long period of time.
> 
> 1) This would result in uprouting a number of people with familes and most likely will not motivate people in any way you might think. It surely would not motivate me and in this type of abusive environment I would be looking tomorrow. Infact, if you want to have a flood of people resign, this is one way to do it. There are other positive means to motivate an engineer. This is not one of them and I am glad you are not my boss.
> 
> ...


I do field support all the time, sometimes for a couple of months, so I know it is bad for morale. The logistics are trivial. I bet they can code on linux laptops, after all this thing is a linux box! If they can't get all the bugs out in a month or two, maybe they should start looking for new jobs. I suspect that the team is really small. As you pointed out, there are no naturally occuring 8VSB signals, or dish birds, and even their power is 240V, 50hz, so they must have a hell of a logistics problem just trying to set up a test environment. Here they can buy everything they need for a test environment at Radio Shack!


----------



## jsanders (Jan 21, 2004)

I tell you, I wouldn't hire any of these guys if I saw '921', and/or 'Eldon' on their resume'. If I did, I would certainly give them an interview for curiosity purposes. Who knows what would happen after that. :lol: 

The engineers have a tarnished reputation with the 921 on their resume'. The management team shouldn't be able to find a job after this spectacle of complete incompetence.


----------



## bbomar (Oct 18, 2004)

welchwarlock said:


> I have been a professional Software Engineer for more than 20 years, and as is obvious to everyone, the 921 unit has major quality problems. I wonder what the root cause is? Perhaps it is poor leadership from the software team. Certainly there is poor test planning and execution.


 I've worked with computers, in industry for 10 years, and teaching computer
engineering for 25 years. I've worked with everything from the PDP8
up through the ARM7 processors I'm using in projects now. Although my
background is hardware, I've done my share of software too. 
I also have wondered where the problem is with the 921 code, and are all
the problems entirely code related? The closest experience I've had to 
the kind of problems I see with the 921 code is code that has been quickly
patched to "sort of" fix bugs, rather than finding the root cause. I wonder
about things like interrupts being properly handled when remote keys stop
responding. As I'm sure you know, an incorrectly handled interrupt may
be fine the first few or even few thousand times the interrupt happens,
and then fail when it happens at just the wrong time. Is an interrupt
not getting reenabled? I guess we will never know. The problem may
be more operating system related and the code on top may more or less
fine. However, basic things like the red dot going in the wrong box make
me wonder. The key to truely fixing problems like we see with the 921 is
the ability to reliably generate the problem in the lab so it can be tracked
down - not just put in more code to try and circumvent the problem when
it happens. I would assume they have 8VSB signal generation capability
and something to generate simulated satellite signals but as you say,
the acid test is always the real thing. I guess the beta testers are supposed
to do that but all they can do is note the problems, not track down the
cause.


----------



## welchwarlock (Jan 5, 2005)

I also wonder if they are being hindered by Import / Export restrictions. I feel quite certain that the algorithms used to decrypt the video, are ITAR restricted. Now perhaps those sensitive bits of code are kept in the states, so what they transfer back and forth is non-sensitive code that operates the system. So then a team here would have to perform a build operation to generate the final module that is uploaded. Further hindering their ability to perform testing.

I am curious how they do that. I had a system held up for a month waiting on an import license for a cable to connect two pieces of hardware. Just some wire and a connector.

Cheers!

P.S. If we really want to stir the pot, we could post messages on Yahoo's stock message board. That board usually gets read by CEO's, Analysts, etc. Quick action often results. A few whines about all the receiver problems, and their inability to repair them in a timely manner might get the ball to roll with more expediency...

http://messages.yahoo.com/?action=q&board=DISH


----------



## SimpleSimon (Jan 15, 2004)

bbomar: You're right on the money.

It's NOT the test logistics, it's NOT randomness of events such as interrupts (we invented semaphores and locks how many decades ago?).

Take the utterly trivial function of "full disk, recorded event deletion" that is 100% NOT related to anything "real-time".

Before the last release (or a few back - I don't remember), the list would always be empty - because it excluded protected events, but was only invoked when all events were protected (unable to be auto-deleted).

This means that the function in question was NEVER repeat NEVER actually tested. Period. 

So, we report it as a bug and they get around to "fixing" it. Now it will show recorded events, but immediately crashes on just about any remote button. 

AGAIN for the SECOND time, the function in question was NEVER repeat NEVER actually tested. 

And I mean the person that coded it never actually looked at it, let alone a QA tech, or a beta tester. 

THAT'S the root problem with this thing - pure sloppiness, lack of management, lack of testing, lack of ANYTHING having to do with ANY kind of competent software development. That, and what might be the worst software design I've ever seen - way too much of these problems are due to hacks which seem to be due to the utter lack of a coherent systems design. Case in point - try to erase the event you just viewed while 0, 1, or 2 recordings are in progress. Now think back to how it used to work.  

That's why I don't bother posting 921 bugs any more (the triple scheduled recording bug is still there). There's simply NO point in it.


----------



## Clarkjwc (Mar 8, 2004)

Mark Lamutt, 
the issues in this thread have been brought up before but I never remember any good replies. Would you please check with E* to see if you can get some reason that we are having to live for so long with so many bugs?

What is the systemic problem! And when is it likely to be corrected?

JC


----------



## murphy43 (Dec 4, 2004)

The 921 is dead. Dish will not acknowledge the problems when you speak with them. It appears the only way they really listen is through this less public forum. And they do it through indirect contacts. All of us are wasting our time. Now we wait to see if they make it right with us down the road.


----------



## astrotrf (Apr 5, 2004)

Another way of explaining the lack of response to the remote control is that the code is handling the remote control keypresses synchronously, polling every so often to see if a remote command has been received. If the code just doesn't get around to checking as often as it should, it responds slowly (or not at all) to the remote.

I suspect it's some form of this that's really going on, because I notice that if I get impatient and bang the remote key several times, it smetimes occurs that I get several repetitions of the action when the machine finally deigns to respond.

This is not to say that the IR detector isn't interrupt-driven; it probably is. And it might be dropping interrupts, too. But the command-stacking phenomenon I've seen argues that the code is broken even if interrupts are working properly.

Insofar as some kind of explanation for this software disaster goes, I think that the only thing we've heard, indirectly, from the Eldon programmers is how bummed they get when they read this forum and see that we all think they're lousy coders. Pity they don't get bummed enough to *do* something about it.

Someone pointed out that if they were all forced to move to the U. S. until the bugs were fixed, there'd be mass resignations. My response to that is "how would we tell the difference?".  Come to think of it, this might actually be the correct path toward getting the 921 fixed.

I'm sad to see a Unix (well, Linux) project go down this way. It's ever so much more satisfying to heap scorn on _Windows_ programmers for crap code.

Terry


----------



## jsanders (Jan 21, 2004)

As it turns out, there were some engineers that came out from England to work on OTA issues. It think they made a lot of progress to that end. Look at the major problems for this release. 1. Jittery video. 2. OTA Guide data issues. 3. Zero Second Recordings. 

As far as the remote button issues, I think there is a twist to it. It would be insane to poll for the IR input. It has to be interrupt driven. Interrupt latency is real. Just press the Guide button, or the DVR button. I can wait a few seconds sometimes before I see it pop up.

I don't think interrupts are getting dropped though. If they were getting dropped, then I would see problems with all of the keys on the remote. I don't. I have problems with the format '*' button most of the time. I don't have problems with the browse button. They are not going to have separate interrupts. When the IR receiver sees a code it recognizes, it flags an interrupt and passes that code to an interrupt service routine. What that routine does is having a problem.

Here is a guess. An interrupt gets flagged, and a recognized code is passed to the ISR. If it was me, I would use the code as an index into an array of function pointers that serviced different routines. Maybe one of the function pointers got messed up because an array went over its boundaries or something like that.

It could also be a problem with the stretch routine. I have noticed a lot of the times when the stretch button stops working that the image on the screen says "normal", yet, the banner guide says "stretch".

All just guesses at this point.


----------



## welchwarlock (Jan 5, 2005)

Lots of speculation here on what is wrong with the software. It is nearly certain to be the software, as resetting the unit fixes most every problem. Without looking at the source code, it is very difficult to know for certain what is going on. But since everyone else is speculating, I thought I would add my own observations.

One can't in a brief memo explain all the subtllies of embedded real time programming, nor can one descibe all of the traps that one can fall into. I am sure that the software is very large, and very complex. I would guess it to be at least 500,000 lines of code. Anyways, here are what I consider the 3 biggest pitfalls for such software, and I suspect they have landed in one or more of these traps.

I suspect the primary problem centers around Memory Leaks and Bad Pointers perhaps deallocating an object and forgetting to null out the pointer, or running past the allocated block of memory, or nulling the pointer without de-allocating it first. These are easy mistakes to make, and even the best programmers make them from time to time. There is evidence to support that this is occuring, since resetting the unit makes the problems go away, and settings get changed, and timers misfire, etc. However, they should not make this mistake because...

For an Embedded, Real-Time application, they should never allocate any memory dynamically. Everything should be statically allocated. Every buffer, every list should have static allocation. Having an OS running Garbage Collection is not appropriate for this kind of application. (Of course maybe this is the problem...deallocating memory that is lost, and no Garbage Collector....) Now that there are so many problems, they should put constant values in between every variable, and check to make sure those constant's don't change. This would let them catch problems where they are overwritting some memory. Even for a dynamically allocated memory system, they could modify their allocation routine to put words on each end of the block and make sure nothing is getting stomped...

Assuming they are not dynamically allocating and de-allocating a bunch of objects, and losing track of them then they probably are not protecting the data properly with semaphores. All data that is shared by multiple tasks should be marked as "volatile" by whatever language construct they have, and there should be semaphores on Reads and Writes to ensure atomic access to multi word objects. The same kinds of problems we see indicate that the data is not always coherent.

The last bit is more complicated, but you can't protect data in an interrupt handler with a semaphore, so the interrupt handler will have to a slightly more complex mechanism such as a circular buffer to communicate information to other tasks. I see no evidence that this problem is occuring, unless the interrupt handler for the clock is resposible for starting the chain of events for the timer recordings.

I seriously doubt there are issues with interrupts. The fact that the buttons get queued up, then execute discloses a portion of their design. The button press activates an ISR, and a list of queued button presses is updated, and an event is generated to a main control loop. The "Latency" that has been speculated about is simply a task that the control loop was doing, before it got around to processing the button press. It certainly is a human factors issue, as people get disturbed if the perceived latency gets to be more than 100ms or so.

Aparently, all we can do is have patience and wait for Dish to deliver us from the Evil of the 921. Hopefully, the distraction of the Voom satellite acquisition won't further delay updates to this system.


----------



## astrotrf (Apr 5, 2004)

welchwarlock wrote a lot of good stuff; I just wanted to make a couple of comments.



> I am sure that the software is very large, and very complex. I would guess it to be at least 500,000 lines of code.


My own estimate would be quite a bit lower than this, but then again, it depends on whether you're counting the hardware drivers, etc. Most of the problems lie above this level (though things like the blue line and the video jitter probably do not). It also appears that they get the drivers from elsewhere; I get the impression that Eldon does not write the drivers.



> Even for a dynamically allocated memory system, they could modify their allocation routine to put words on each end of the block and make sure nothing is getting stomped...


I've done this in a couple of the systems I've written. Interestingly, I wound up dropping the allocation at the *front* of the block. Overruns at the end of a block would tend to run into the start of the _next_ block, and the guard-word checker would complain about that block unnecessarily; it was always the fault of an overrun at the end of some other block. It doesn't hurt to put guard words at the front, but it never actually helped me.



> The fact that the buttons get queued up, then execute discloses a portion of their design. The button press activates an ISR, and a list of queued button presses is updated, and an event is generated to a main control loop.


Yup, this is almost certainly what's going on. I write code that works this way all the time. Polling devices instead of using interrupt service routines quickly leads to lots of subtle problems - hard to diagnose and usually even _harder_ to fix.

Question: do you really think they're using real-time programming for this? Granted, data is arriving at a prodigious rate, and they can't afford to miss buffers, but I'm not at all convinced that the 921 needs to run real-time code.

It's great to find a collection of obviously talented programmers here!

Terry


----------



## SimpleSimon (Jan 15, 2004)

"It's great to find a collection of obviously talented programmers here!"

It'd be better to find them (us?) at E*.


----------



## welchwarlock (Jan 5, 2005)

astrotrf said:


> welchwarlock wrote a lot of good stuff; I just wanted to make a couple of comments.
> 
> Question: do you really think they're using real-time programming for this? Granted, data is arriving at a prodigious rate, and they can't afford to miss buffers, but I'm not at all convinced that the 921 needs to run real-time code.
> 
> ...


You have exposed my not so subtle dig. I fully expect that they are not using a full set of realtime programming techniques, yet this is, indeed, a realtime programming challenge. Less experienced engineers will make some assumption that the processor is so fast, that nobody can tell the difference, yet the reality is that people can tell the difference, and you get hit by OS runtime issues. Your only hope is to set the task priorities correctly, carefully program the interrupt handlers, and pray that Murphy's Laws don't slap you back to reality. Heaven help the poor slob that tries to implement a device like this in Windows!

Best Wishes,

Robert Cook


----------



## jsanders (Jan 21, 2004)

Linux is not a realtime operating system. The 921 is not an embedded controller either.

There is an RTLinux (RT = real time) that has a simple scheduler which runs linux as one of its tasks.

Looking at the 921, however, is a slightly different story. I would imagine that a lot of the work has been offloaded from the processor. The tuners should be able to write the 19.2mbps straight to disk for a 1080i signal. The MPEG2 decoder is probably done in hardware as well. This offloads a lot of the realtime scheduling required.


----------



## SimpleSimon (Jan 15, 2004)

JS has it down. PCI mastering has been around forever, and yes, the MPEG decoder is in hardware (no way the underpowered 800MHz cheap-crap CPU could begin to handle it).


----------



## BobMurdoch (Apr 24, 2002)

FrankD1 said:


> I've had the same thoughts about testing in the UK. While E* has plenty of people (Charlie included) in CO to test, it's the developers that need to be able to EXACTLY reproduce the environment in which bugs are occurring in order to fix them properly, and I just don't see how they can do that in the UK, where they can't see all the birds.


This is like trying to get Vegetarians to develop a new recipe for Meat Loaf......


----------



## RVRambler (Dec 5, 2004)

Talking about the 'why' as to the 'fix one bug, 2 new crop up'. Have you guys ever heard the term 'polishing a turd'? I suspect the base code is a 'turd' to start with!

'Polishing a turd', implies not getting/having a good base, but constantly hacking the problems without either major re-design/re-write or completely starting anew. Certainly a BAD environment to work in, even for a brit 

I have personally been a 'turd polisher' and simply by inserting an 'if' statement containing lots of qualifiers, could functionally mess up another completely un-associated feature which shared that execution path. Messy stuff, ONLY testing the heck out of it could you even think it might be ok, usually not even then!!

Testers get no respect, but a great tester deserves MUCH respect!!

We use to call the better testers, 'Monkey' testers, that tested scenarios that only a 'monkey brain' would think to execute, good stuff!!


----------



## welchwarlock (Jan 5, 2005)

jsanders said:


> Linux is not a realtime operating system. The 921 is not an embedded controller either.
> 
> There is an RTLinux (RT = real time) that has a simple scheduler which runs linux as one of its tasks.
> 
> Looking at the 921, however, is a slightly different story. I would imagine that a lot of the work has been offloaded from the processor. The tuners should be able to write the 19.2mbps straight to disk for a 1080i signal. The MPEG2 decoder is probably done in hardware as well. This offloads a lot of the realtime scheduling required.


I agree, and I suspect that all the big data pushing is offloaded. It doesn't really negate the realtime scheduling requirements though. I suspect the processor has to get involved with each block of data to tell it where to put it (Memory, Disk, MPEG2 Decode for display), and where to get it (Sat1,Sat2,OTA1,Disk,Memory), With multiple streams in and out, it is a lot of work to service all those interrupts on time and make sure that each block of data gets to where it needs to go.

If it really can tell the SAT tuner to record stream X to File Y, tell the MPEG Decoder to decode and display file Z without any further commands, then I would be quite impressed with the hardware design, and scratching my head as to why there are so many problems with the thing.


----------



## jsanders (Jan 21, 2004)

I think we have all been scrathing out heads so much that some of us might have become folically challenged over the last year.

If it is any consolation, one of those builds, back when they would give us release notes said that it came with a new FPGA image. Yep, you got it, at least in one case, they are dropping a gate array chip in there instead of an ASIC. That is why I thought the 921 was so expensive when it started production. If then, they are changing the hardware, you can see how that impact could create really buggy operation as well.


----------



## welchwarlock (Jan 5, 2005)

jsanders said:


> I think we have all been scrathing out heads so much that some of us might have become folically challenged over the last year.
> 
> If it is any consolation, one of those builds, back when they would give us release notes said that it came with a new FPGA image. Yep, you got it, at least in one case, they are dropping a gate array chip in there instead of an ASIC. That is why I thought the 921 was so expensive when it started production. If then, they are changing the hardware, you can see how that impact could create really buggy operation as well.


I don't think any of my hardware guys would even contemplate an ASIC design instead of a gate array...of course the stuff I build, doesn't get mass marketed, and the largest gate arrays cost $10,000 a pop ... Obviously they are using a much smaller array. The Non-Recurring-Expense (NRE) of an ASIC is much larger than an FPGA, but the RE of the ASIC is smaller.

Perhaps they Beta test elements of the hardware design on us early adopters with the more expensive gate arrays until they get it right, then when they have it correct, they can more inexpensively convert the design to an ASIC. First pass success on the ASIC is then nearly assured. Maybe that part is an ASIC on the 942 or whatever it is called. Got to be a Dilbert cartoon in here somewhere.


----------



## jsanders (Jan 21, 2004)

That would attribute some level of design forethought. I think a lot of this stuff should be ASICs that someone else already designed. They shouldn't be in the business of designing ATSC tuners, or MPEG2 decoders. I can see them designing glue logic on an FPGA, but it is a comodity PC board, something they didn't need to design either, because they come complete with interface ASICs. 

Who knows what they forecast for 921 numbers, but it is cheaper if you buy ready made chips than design your own ASIC unless the volumes are very high. No non-recurring-expenses that way either.


----------



## welchwarlock (Jan 5, 2005)

I about had a meltdown tonight using this piece of junk. I started another thread, that you can read. Basically, I could not tune channel 5 tonight, and starting at 9:00, no matter what channel I choose the title of the show is "Unknown Record", and the channel number is always displayed as 77.

I know it will clear when I reboot it, but I shouldn't have to do that.

What a bad piece of code. At this point, I would donate my time to help them fix it.

ARGH!


----------



## welchwarlock (Jan 5, 2005)

Yet another night with more problems.... No Tuner Available, when I try to watch OTA, while recording 2 Sat channels....

Maybe we could fix the 921 by changing it's name... Boat Anchor.


----------



## jsanders (Jan 21, 2004)

If you did that, you might be complaining about bugs in the design of that boat anchor. It doesn't have a strong way to attach the line to your boat, and it doesn't seem to have the ability to hook onto debris very well. Hmmm. Maybe they should do a better job at boat anchor design next time, eh?


----------



## Ron Barry (Dec 10, 2002)

welchwarlock said:


> Yet another night with more problems.... No Tuner Available, when I try to watch OTA, while recording 2 Sat channels....
> 
> Maybe we could fix the 921 by changing it's name... Boat Anchor.


My understanding is you can only do two of the three at one time. THis is by design not a bug.


----------



## n0qcu (Mar 23, 2002)

welchwarlock said:


> Yet another night with more problems.... No Tuner Available, when I try to watch OTA, while recording 2 Sat channels....
> 
> .


Thats just what is supposed to happen. BY design you can only use TWO of the three tuners at the same time.


----------



## SimpleSimon (Jan 15, 2004)

welchwarlck said:


> What a bad piece of code. At this point, I would donate my time to help them fix it.


You and around a dozen more of us.

Of course, to accept our help, they'd have to admit that they aren't perfect.

What E* lacks in ability, they compensate for in ego - just like the CEO.


----------

