mm wrote:
On Mon, 13 Dec 2010 22:07:51 -0700, D Yuniskis
wrote:

mm wrote:
On Mon, 13 Dec 2010 16:46:42 -0800, "William Sommerwerck"
wrote:

Another possibility is interference, possibly from
an infrared light source.
Fluorescent lamps put out a lot of infrared, and I actually had one that
occasionally changed channels on a Sony VCR. Make sure all fluorescent lamps
are turned off.

Have you added any new incandescent lamps? A bright IR source will reduce
the receiver's sensitivity to the remote's commands.

Hmmm. What about compact fluuorescents? Not my vcr, but my digital
to analog converter goes "on" once every 2 or 4 weeks, but it's not
really on. The light on the box is on, but no televiion is coming out
of the wire. And when I use the remote for it to try to turn it off,
it doesn't go off.

Thanks for replying.
Does it respond to any of the buttons on the unit itself??

There are no buttons on the unit itself. (It's undercover. MI-5.)

Ah. :

(i.e., is the processor responding to everything *except*
the remote -- see below)

I have to unplug it from the wall, and then plug it in again, and
still the light is on, but it seems 5 or 10 seconds after that the
light goes off. Then I can turn it on with the remote, and off again.
(There is no switch on the box itself.)
Most of the DTV converters I have seen are "90 day wonders".
I suspect yours is "crashing" and cycling power is essentially
reseting it.

Peek inside. They typically run very hot. If you are the
type that leaves it on for extended periods (turning off the
TV but not the converter), you will likely find toasted caps.

No, I don't leave it on. But other than this problem, which may have
started when I put a new bulb in the ceiling fixture, CFL for the
first time, other than this problem, it still works fine. I think it
probably is the CFL. Next time a bulb burns out, I'll change brands,
or put the CFL on the far side of the fixture, or remove it, or all
three.

My point is that there is no *valid* way for the device to
get into the state that you have described. *Perhaps* you
can argue that a "bug" is causing it to react incorrectly to
some bizarre "Ir code" that it *thinks* it is seeing. I'm
suggesting that the processor has actually "gone south"
(a point I was hoping you could verify by "pressing buttons on
the unit itself" while it was "crashed").

Anything that can potentially "stay on indefinitely" should be
designed with some sort of automated "crash recovery" mechanism
in place (watchdog timers, etc.) so that they "fix" themselves i
*if* they crash.