wouldn't it be better to figure out what's stepping on the IR values and
fix that? Maybe I'm, a purist but it seems that rebooting a device due to
an error isn't the best use of clock cycles and if the fact is that
something is blowing away the IR state on the device then it's just as
likely that resetting the IR will blow away that overwriting state and
screw up those functions. i think what we really need is someone on the 150
devo side to give it a hard look and run it down
I did some googling around and found plenty of instances of the same
problem with the windows software. Eventually I ended up at:
http://www.shspvr.com/smf/index.php?topic=8389.0
which various people have been pointed to as fixing the remote.
It might be worth playing about with that. Does anyone have an idea
of what the issue might be in the first place? It would seem like
the IR chip just crashes, presumably --reset-ir is able to restart
it somehow?
There's nothing in the changelog that indicates a remote fix so it
would appear that they are as clueless about it as we are. Is this a
different chip than in the 350? Because the 350 seemed stable with
the 2.0 drivers. I used it all the time. It was just that I wanted to
use the 150 IR Blaster for my digital settop box instead of the
analog cable directly
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
ivtv-devel mailing list
ivtv-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ivtv-devel
