<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Thu, Oct 24, 2013 at 4:35 PM, Gary Buhrmaster <span dir="ltr"><<a href="mailto:gary.buhrmaster@gmail.com" target="_blank">gary.buhrmaster@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
I am going back to trying to get the blaster to work.<br>
<br>
First, make sure you have the latest driver and firmware for the<br>
iguana device (1.1.0 I think). There have been some fixes in<br>
the driver and the firmware over the years, a few of which, as<br>
I recall, could be startup related. Flashing the firmware may<br>
require installing additional packages. And then change the<br>
udev rule line 'RUN = "/usr/share/iguanaIR/rescan"' to be<br>
'RUN = "/usr/share/iguanaIR/rescan --all"'<br>
<br>
I seem to recall from the iguanaworks wiki/ticket system<br>
that there were a couple of other tricks to try. You might<br>
want to go look there (or open a ticket with them).<br>
<br>
Gary<br></blockquote></div><br><div>Gary,<br></div>You're right about my being behind on my driver/firmware update, however, see below.<br><br></div><div class="gmail_extra">Peter,<br></div><div class="gmail_extra">Thanks for the input, but my problem isn't with the daemon failing to start, but with it failing on the first run to create the device socket, and that's kind of a side issue vs. what I started this thread for in the first place.<br>
<br></div><div class="gmail_extra">All,<br></div><div class="gmail_extra">I had two issues to address:<br> A) I have set my system up to lock mythbackend when the system comes up such that "mythshutdown -p" reports that the system was started up manually. I did this so I could fire up the system and go do something else and it would still be up when I get back rather than time out and shutdown again. But this logic is flawed when the system is awakened after a power failure followed by power restoration because I have the BIOS set to start the system up automatically on power restoration. This is needed to make the auto wake-up configuration get restored so the system will correctly wake up automatically when the next recording or SD update comes due (I have added code that figures out which is next and when and sets the time in /sys/class/rtc/rtc0/wakealarm before the system shuts down). For this issue, I was looking to find a way to detect that the system was awakened from a clean shutdown because the power went out and was subsequently restored so that I could cancel the lock and let it go back to sleep without intervention. I mentioned the business with the IguanaWorks USB Transceiver because it was a possible way to detect that and "get 'er done". ;-)<br>
</div><div class="gmail_extra">B) The IguanaWorks USB Transceiver driver/daemon was consistently failing to create the device socket the first time the system was brought up after power had been removed. Thanks to Gary, I have a way to address that, but I don't plan to do it at this point because I'm using this "feature" to solve problem A. ;-)<br>
<br></div><div class="gmail_extra">What I did:<br></div><div class="gmail_extra"> I extended the /etc/init script I wrote to replace the IguanaWorks supplied /etc/init.d script so that it now has a post-start script that gives the daemon a chance to start and then checks to see if the socket got created. If not, the daemon gets the HUP signal, which causes it to successfully (in all my tests so far) create the socket. Then it emits an init event, power-restored, which is used by a new init script.<br>
</div><div class="gmail_extra"> The new init script gets started on power-restored AND stopped lock-init-script, where lock-init-script is yet another script that handles checking whether the startup was auto or manual and in the latter case tells mythshutdown to lock (disable shutdowns). This new script waits for mythshutdown to be ready to listen to it's command (returns status <> 254) and then tells mythshutdown to unlock (enable shutdowns).<br>
<br></div><div class="gmail_extra">Taken one bite at a time, it's simple, but looking back at this house of cards, I'm amazed what a complex bit of scripting I have. I'm sure it will all come tumbling down when (if) I ever get around to updating my Myth system. ;-)<br>
<br></div><div class="gmail_extra">I'd still like a better way to tell that the system came up due to power being restored, but at this point it looks like I'd have to pull out a soldering iron and build a flip-flop tied to an unused signal line (e.g. CTS/RTS on a serial port) and resettable under program control such that the signal is set when power fail / restore occurs and gets cleared by program control after using the info to do appropriate processing (e.g. re-enable shutdowns).<br>
<br></div><div class="gmail_extra">If anyone reads this and has an idea for an existing way to detect boot-up on power restore, I'd love to hear about it (e.g. BIOS info or something gleaned from somewhere in the /sys or /proc subdirectory trees).<br>
<br></div><div class="gmail_extra">In closing, thanks to all for your suggestions and inputs.<br><br>--<br></div><div class="gmail_extra">Craig.<br></div></div>