[mythtv-users] Way to tell BE came up after power fail?

[Craig Huff]

On Thu, Oct 24, 2013 at 4:35 PM, Gary Buhrmaster
<gary.buhrmaster at gmail.com>wrote:

> I am going back to trying to get the blaster to work.
>
> First, make sure you have the latest driver and firmware for the
> iguana device (1.1.0 I think).  There have been some fixes in
> the driver and the firmware over the years, a few of which, as
> I recall, could be startup related.  Flashing the firmware may
> require installing additional packages.  And then change the
> udev rule line 'RUN = "/usr/share/iguanaIR/rescan"' to be
> 'RUN = "/usr/share/iguanaIR/rescan --all"'
>
> I seem to recall from the iguanaworks wiki/ticket system
> that there were a couple of other tricks to try.  You might
> want to go look there (or open a ticket with them).
>
> Gary
>

Gary,
You're right about my being behind on my driver/firmware update, however,
see below.

Peter,
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.

All,
I had two issues to address:
  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". ;-)
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. ;-)

What I did:
  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.
  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).

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. ;-)

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).

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).

In closing, thanks to all for your suggestions and inputs.

--
Craig.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.mythtv.org/pipermail/mythtv-users/attachments/20131028/ec7ce204/attachment.html>