[mythtv-users] HDHR prob with new wallwarts

Sat Dec 7 19:28:42 UTC 2019

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

> On Sat, 7 Dec 2019 09:45:00 -0500, you wrote:
>
> >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.
>
> One of the complications of using network tuners is that the traffic
> from them can be swamped by other use of the same network port.  A
> gigabit Ethernet port is easily capable of handling the traffic from
> four HD recordings, but not if you are copying a big file from a fast
> hard drive or SSD to another similarly fast drive over the same
> Ethernet port.  The latest generations of hard drives and all SSDs are
> now faster than a 1 gigabit Ethernet connection.  So it is better to
> run network tuners on their own network, if possible.  So that would
> need another switch to put the tuners on and another Ethernet card in
> the MythTV backend box.  But if you want other things on the network
> to also be able to use the network tuners, isolating them on their own
> network defeats that.
>

It was insomnia testing 4am I started four recordings, then opened a
browser on my FE/BE and immediately the recordings failed no other network
traffic at all.

>
> It would be really nice if the HDHRs tagged their packets with
> real-time priority in the IP packet DSCP header bits.  Then you could
> set up the Ethernet port so that the packets with high priority took
> precedence over the standard priority packets and the HDHR traffic
> would be able to get through even when the port was being used to full
> capacity by other traffic.  Not having an HDHR, I am unable to take a
> look at its packets to see what the DSCP bits are set to.  There are
> some posts out on the net that suggest that the DSCP bits are set, so
> if they are, it would be worthwhile taking a look at what it takes to
> enable QoS processing on your Ethernet port - and on your Ethernet
> switch also if it supports that.  But before that, someone with an
> HDHR needs to run Wireshark or tshark or tcpdump to capture some HDHR
> recording packets and confirm the DSCP bits are being set properly.
>

My router allows 1 top priority service 2 second level priority and ten
normal priority device staging. My wife's VoIP phone takes the top spot and
the HDHRs occupy the next two spots. This change was made prior the the
last test. The ethrenet switch is a "smart switch" maybe that is where I'm
getting into trouble?

>
> >>
> >> 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.
>
> It would probably be better to do the startup fix, as you can get
> situations such as where there has been a power failure and the box
> reboots while you are not there.  So after that, the HDHRs would not
> work until you manually restarted mythbackend.  That would be a real
> pain if you were away on holiday!
>
> >>
> >> 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.
>
> I have never used the MythTV ability to shut down between recordings,
> so I have no practical experience to go on.  However, I can see no
> reason for the ACPI setup being affected by this fix with mythbackend
> as it will have done all the ACPI setup before it issues the command
> to shut down which in turn will cause systemd to do the shut down.
>
> What you do need to know is how to make systemd know that the shut
> down is to be followed by an automated wake up.  I have never looked
> at how systemd handles that so I have no idea if you have to tell it
> that a wakeup is scheduled or if you just need to have issued the
> right ACPI calls beforehand.  It is possible that if systemd does not
> know about the scheduled wakeup, it may kill the wakeup as part of its
> normal shutdown procedure.
>
> Also, the method of shutting down the system from MythTV as installed
> no longer works since systemd, as mythbackend does not have the
> correct privileges to do systemctl commands such as shutdown -
> attempts by mythbackend to run a shutdown command will fail.  So you
> need to work around that.  I have done it using an sudoers helper
> file, and that works well.  See this post for how to set it up:
>
> https://lists.gt.net/mythtv/users/625993
>
> Since I have not used the ACPI shutdown ability of MythTV, I have not
> tested the sudoers helper script with mythbackend, but it works well
> from mythfrontend and I see no reason for mythbackend to have a
> problem with it.
>

Thamks for the post, that ias acconmplished.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mythtv.org/pipermail/mythtv-users/attachments/20191207/1b2f56b6/attachment-0001.htm>