[mythtv-users] HDHR prob with new wallwarts

Sat Dec 7 19:47:30 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.
>
> 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.
>
> 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:
>

So before I enable the debug-shell.service is disabling it as easy as:

sudo systemctl disable debug-shell.service     ? If I hear you correctly, I
don't want to leave myself open any longer than necessary (the debug
process) ?

>
> 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
> _______________________________________________
> mythtv-users mailing list
> mythtv-users at mythtv.org
> http://lists.mythtv.org/mailman/listinfo/mythtv-users
> http://wiki.mythtv.org/Mailing_List_etiquette
> MythTV Forums: https://forum.mythtv.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mythtv.org/pipermail/mythtv-users/attachments/20191207/6e9d5d22/attachment.htm>