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?
-------------------------------------------------------
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
