[mythtv-users] delaying mythbackend startup until a STB is available

[Stephen Worthington]

On Mon, 04 Feb 2019 13:56:20 -0700, you wrote:

>Over the weekend I had a power outage. My MythTV BE/FE is on a 900VA UPS and 2 
>ongoing recordings chugged merrily along until the UPS battery ran out - this 
>was a serious outage. I don't use the soft-shutdown capabilities of my UPS 
>monitor because outages aren't usually this long and it's a new UPS so I don't 
>know how long it's good for. But Linux seems to be remarkably robust so I've 
>never been zinged with problems after a power drop-out.
>
>Upon power restoration the machine and my STBs restarted and one the 
>previously-recording shows picked up on my SD STB. The other recording had 
>ended during the outage.
>
>But, mythbackend didn't see the HD STB because it takes a minute or so to 
>reboot, way slower than the machine takes to start up. I had to manually 
>restart mythbackend after the HD STB booted up.
>
>So, I was wondering if there's a way to know, at boot time, if the boot is 
>happening after a power loss (not a normal shutdown), so that I could then 
>delay the start of mythbackend for a couple minutes after the machine reboots 
>to let the HD STB get itself together.
>
>Any ideas?

I do not know of any way for Linux to know that it has had a power
failure or similar bad shutdown.  It does detect that partitions have
not been unmounted correctly, but not what caused it.  Your UPS may be
able to tell you when it has been restarted after its batteries were
drained.

There used to be software that could take a snapshot of the output of
an STB and interpret it enough to be able to see what the text was in
the image - see if it was the correct menu, and then allow you to send
the appropriate command to the STB to get it into the mode required
for recording.  That was for the old analogue TV, but if you are using
an STB's analogue output it should work.

Some STBs also have APIs that can be used, via a comms port of some
sort.  It all depends on the exact STB and how you are able to talk to
it.

Also, after any sort of bad shutdown, you really should be running a
full "fsck -f" on all partitions that were mounted at the time.  There
can be damage that the system does not know about, and if an fsck is
not done to fix it, then subsequent writes to that partition can make
it unfixable, where it might have easily been fixed if fsck had been
run.  The system does try to do fscks automatically where it thinks
they are required, but it does not always see that they are required,
and I had one case with my mother's MythTV box after a power failure
where I had to run fsck 6 or 7 times before all the errors were
cleared, and then I had to copy a couple of damaged files from another
PC running the same Ubuntu version to finally repair it.

After you run the fsck checks and the filesystems are repaired, you
also need to run the optimize_mythdb script to check and repair any
damaged mythconverg database tables.  If you were recording at the
time of the bad shutdown, it is very likely that at least the
recordedseek table will be crashed and need repairs.  Mythbackend does
not detect this and will record (sometimes successfully) with damaged
tables.  But writing to a damaged table is a good way of increasing
the chance it will become unrepairable.  I would recommend that you
urgently run optimize_mythdb right now.