<div dir="ltr"><div dir="ltr"><div dir="ltr">This happened again today. I was able to do some experiments this time so I have new data.  </div><div dir="ltr"><br></div><div dir="ltr">I ran the HDHomerun_Config gui and both HDHomerun devices were missing.  I power cycled the HDHomerun units and no difference.  I also ran <hdhomerun_config 10137DC1 set /ir/target "<a href="http://192.168.1.111:5000">192.168.1.111:5000</a> no_clear"> before and after power cycling the HDHomerun units and linux just gave an error message <unable to connect to device>. This is the command I use in rc.local to configure the units on power up. Power cycling the mythbox without power cycling of the HDHomerun boxes fixed the issue.</div><div dir="ltr"><br></div><div dir="ltr">I noticed this evening because the remote would not work (the HDHomerun has the ir reader).  We went ahead and watched our evening show without issue using a keyboard for control. Then I ran my tests after we were done watching.</div><div dir="ltr"><br></div><div>I also noticed that our 3PM show did not record but the 8AM show did record. The 3PM show comes on again at 6PM and myth tried to record it both times but failed.</div><div dir="ltr"><br></div><div dir="ltr">This sure looks like something new to Mythbuntu 16.04.1 LTS. I ran the same hardware with Mythbuntu 8 for ten years without this happening.  It seems to happen not quite once a month and the unit is on 24/7.</div><div dir="ltr"><br></div><div>Any ideas?  I don't know what to do.</div><div><br></div><div>Allen</div><div><br><div><br></div></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Jan 21, 2019 at 10:34 PM Allen Edwards <<a href="mailto:allen.p.edwards@gmail.com">allen.p.edwards@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Jan 18, 2019 at 7:20 AM Jan Ceuleers <<a href="mailto:jan.ceuleers@gmail.com" target="_blank">jan.ceuleers@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 18/01/2019 05:17, Stephen Worthington wrote:<br>
> The biggest problem with using re.local is that any command that fails<br>
> instantly terminates rc.local - no further commands are executed.  So<br>
> doing a series of commands as you are in rc.local is not a good idea.<br>
> It is much better to get rc.local to run a separate script.  So you<br>
> would put your commands in a script such as<br>
> /usr/local/bin/start-hdhrs.sh, and then run that from rc.local like<br>
> this:<br>
<br>
A simpler solution, if rc.local's termination behaviour is not desired,<br>
is to change it. Simply remove the "-e" from the first line in the<br>
script so that /bin/sh is not called with the -e parameter.<br>
_______________________________________________<br></blockquote><div><br></div><div>rc.local runs fine.  It is just that the HDHR which is initialized by rc.local quit responding.  I never turn my system off so I would say that the HDHR was probably running for several months before it suddenly became unresponsive. The strange thing is that the last time it happened, it was at about the same time of day thus missing one show late at night and the show the next morning before it was discovered.</div><div><br></div><div>That said, I did notice the behavior in rc.local where if there is an error it terminates. If I ever change it, I run it from the command line where I can see the error messages. </div><div><br></div><div>Allen</div></div></div>
</blockquote></div>