[mythtv-users] HDHR prob with new wallwarts

Sat Dec 7 14:45:00 UTC 2019

On Sat, Dec 7, 2019 at 1:56 AM Stephen Worthington <stephen_agent at jsw.gen.nz>
wrote:

> On Fri, 6 Dec 2019 14:00:00 -0500, you wrote:
>
> >Greetings Mythizens, Because my system does not shut down gracefully
> >(Gigabyte mobo that cooperates with windows, but not Ubuntu) I've been
> >leaving it on 24/7. I finally got new wallwarts for both of my HDHR's and
> >still have unreliable recording performance from them. One box failed on
> >both recordings about ten minutes in, and then the other after 15 minutes,
> >so I gave the first unit higher priority in my router as well as a fixed
> >IP, and tested again with similar results. Then after some googling I
> tried
> >powering them down for about 15 mins, then testing again, with success.
> Can
> >Mythtv reboot these devices prior to putting them to use? I used to wake
> >the box as needed, but since the mobo doesn't cooperate and the backend is
> >up before the HDHRs are capable of responding... well you see my
> situation,
> >any suggestions?  TIA  Daryl
>
> I am not sure rebooting the HDHRs will help.  You shut them down,
> rather than rebooting.  So it could be a temperature problem, and they
> cooled down enough while they were off to be able to complete a
> recording once they were restarted.  So you need to test whether a
> reboot is all that is required, or whether they actually need to be
> shut down for a while.  And you could try just pointing a fan at them
> to see if that helps.
>

I'm not so sure either now, another test points to network traffic, what
I've been doing is scheduling four recordings at once, and watching them
grow, or not. This time while waiting I went to another desktop and opened
a browser, and a shortcut to a website. I received a message saying "site
cannot be reached, your network connection has been interrupted" then the
site loaded and the recordings failed. I have the HDHRs connected to a
gigabit switch > gigabit router. The successful test yesterday, found the
wife sitting at the table not the PC.

>
> Also, what do you mean by "backend is up before the HDHRs are capable
> of responding"?  Since you are using network tuners, you should have
> the fix installed that causes mythbackend to wait until the HDHR
> tuners are available before it starts.  But if you did not have that
> fix, the HDHRs would often not work at all after the box is booted,
> until you restarted mythbackend.  But that is not the problem you seem
> to be describing.
>

At this point in time I have three internal cards (single tuners) and the
two HDHRs, normally the three are enough, but I've been tinkering with the
two for those rare times when I would need four physical tuners, so as yet
I haven't done the network ping, or backend sleep fix, primarily because
the box is on 24/7. It reboots fine, and after satisfying an upgrade with
the HDHRs first in line to record they failed, I assume because they were
not recognised at boot or reboot, as the case was. Exactly as you just
pointed out.

>
> As for the problem with shutting down the motherboard, if it shuts
> down in Windows, then it is clearly able to be made to shut down
> properly, once you find out what in Ubuntu is causing it not to shut
> down.  That can be quite difficult, but it is possible.  I have had
> problems like that, and what I found was the best way to diagnose
> shutdown problems was to do this:
>
> sudo systemctl enable debug-shell.service
>
> which enables a root debug console on Ctrl-Alt-F9 that comes up very
> early during boot and goes away very late during shutdown.  It does
> not require a login (as it comes up before logging in is possible) and
> hence is a serious security problem when enabled, but it is able to be
> used to tell you what is happening when Ubuntu fails to shut down or
> shuts down very slowly.  Once you have a debug console, then you can
> try shutting down.  When the shutdown is happening, use Ctrl-Alt-F9 to
> go to the debug console and use commands like:
>
> systemctl list-jobs
>
> to see what is still running, what is waiting to be run and so on. You
> will normally find one or more jobs that are waiting a long time for
> something to happen, such as a network connection to shut down or a
> non-existent (network or local) drive to be mounted so that it can be
> unmounted.
>
> One thing that catches most MythTV users is the problem that
> mythbackend has a shut down bug itself, and fails to shut down
> completely when asked to by systemd.  Systemd then does a long timeout
> before finally killing mythbackend using a kill -9 call.  I think that
> takes 60 or 90 seconds, and it delays other things from getting shut
> down also.  What happens in mythbackend is that most of it is shut
> down, but at least one thread fails to stop.  If it is given a second
> normal shutdown request shortly after the first one, it will shut down
> immediately then.  The fix I have for this problem is to put this line
> in the [service] section of your systemd override file for
> mythtv-backend:
>
> ExecStop=/usr/local/bin/mythbackendstop.sh
>
> and put a copy of my mythbackendstop.sh file in your /usr/local/bin
> directory:
>
> #!/bin/bash
> PID=$(systemctl show -p MainPID mythtv-backend.service 2>/dev/null |
> cut -d= -f2)
> if [ "$PID" != "0" ]; then
>     kill -15 $PID
>     sleep 1
>     kill -15 $PID
> fi
>
>
> which you can do by downloading it from my web server:
>
> sudo su
> cd /usr/local/bin
> wget http://www.jsw.gen.nz/mythtv/mythbackendstop.sh
> chown root:root mythbackendstop.sh
> chmod u=rwx,g=rx,o=rx mythbackendstop.sh
> exit
>
> It is also a good idea to put these two lines in the [service] section
> as well, as a backup in case mythbackend is locked up and really needs
> a kill -9:
>
> SendSIGKILL=yes
> TimeoutStopSec=10
>
> That will do a kill -9 after 10 seconds if mythbackend still does not
> shut down.
>
> My override file for mythbackend is:
>
> /etc/systemd/system/mythtv-backend.service.d/mythtv-backend-override.conf
>
> but yours (if it exists) may have a different name.  The name does not
> matter as long as it is a .conf file.  The easy way to create or edit
> one these days (as long as your systemd has been updated) is:
>
> sudo systemctl edit mythtv-backend
>

Thanks Stephen, the detail you go into here for me is greatly appreciated,
and needed. Quick Q though, will the above fix interfere with ACPI? I would
think a kill would cancel the set-wakeup, I hope I'm wrong.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mythtv.org/pipermail/mythtv-users/attachments/20191207/b325ea5a/attachment.htm>