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:
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@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-users http://wiki.mythtv.org/Mailing_List_etiquette MythTV Forums:
https://forum.mythtv.org