Mailing List Archive

> On Dec 6, 2019, at 2:00 PM, Daryl McDonald <darylangela@gmail.com> 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

The problem Silicondust had with power supplies was a very long time ago—back when the Dual was introduced? While power surges (esp. a lightning strike) can still kill them at any time, SD do not seem to have a systemic problem nowadays with the power supplies failing.

Where did you get replacement power supplies? Are you positive they are the right spec. Silicondust will supply replacement power supplies at a very reasonable cost as a legacy of their previous problems.

Also, if you file a trouble ticket with Silicondust, they can enable logging from the HDhomerun boxes and may be able to offer a solution.

Craig

_______________________________________________
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

On Fri, 2019-12-06 at 14:00 -0500, Daryl McDonald 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
>
> _______________________________________________mythtv-users mailing
> listmythtv-users@mythtv.org
> http://lists.mythtv.org/mailman/listinfo/mythtv-users
> http://wiki.mythtv.org/Mailing_List_etiquette
> MythTV Forums: https://forum.mythtv.org

to reboot your hdhr from terminal use:hdhomerun_config "deviceid" set
/sys/restart selfwhere device id is the number of your device which you
can get with: hdhomeurn_config discover
you can make a simple script to trigger it as an event in myth like the
'recording pending' under system events insetup. i find that triggers
usually 30 seconds ahead of a recording. to further refine you would
want to check thatthe tuners are idle to have it not reboot on back to
back scheduled recordings.

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

On Fri, Dec 6, 2019 at 2:25 PM Craig Treleaven <ctreleaven@cogeco.ca> wrote:

> > On Dec 6, 2019, at 2:00 PM, Daryl McDonald <darylangela@gmail.com>
> 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
>
> The problem Silicondust had with power supplies was a very long time
> ago—back when the Dual was introduced? While power surges (esp. a
> lightning strike) can still kill them at any time, SD do not seem to have a
> systemic problem nowadays with the power supplies failing.
>
> Where did you get replacement power supplies? Are you positive they are
> the right spec. Silicondust will supply replacement power supplies at a
> very reasonable cost as a legacy of their previous problems.
>
> Also, if you file a trouble ticket with Silicondust, they can enable
> logging from the HDhomerun boxes and may be able to offer a solution.
>
> Craig
>

Thanks Craig,the specs only differ in that the new ones have greater
amperage available 3 as opposed to 1, my understanding is that amps will
be supplied as called for by the connect, not by the the spec on the wart.

On Sat, Dec 7, 2019 at 1:56 AM Stephen Worthington <stephen_agent@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.

On Sat, 7 Dec 2019 09:45:00 -0500, you wrote:

>On Sat, Dec 7, 2019 at 1:56 AM Stephen Worthington <stephen_agent@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 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.

>>
>> 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.
_______________________________________________
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

I have no idea if this will be helpful but I had several issues getting my
HDHR tuners to work. I provide these in case they might be useful.

Myth address is 192.168.1.111 and is static. I set it as reserved on the
router. I also set the HDHR addresses as reserved.

I start the tuners from rc.local. Old school but works.
Here is the code. I believe this was from the vendors website.
hdhomerun_config 10137DC1 set /ir/target "192.168.1.111:5000 no_clear"
If you need to allow more time to go by, you can add a delay before this
command.

I had a power supply issue as well. The module that I bought with the HDHR
did not put out enough current so I got ones rated for more current.

I also had random failures. The computer would lose contact with the
turners every few weeks. I traced it to a linux problem as the tuners were
still visible from a Windows computer on the same network. That
troubleshooting tip was provided by Silicon Dust.

Here is the solution.

dad@NewMyth:~$ more /etc/network/interfaces
# interfaces(5) file used by ifup(8) and ifdown(8)
auto lo
iface lo inet loopback
auto enp2s0
iface enp2s0 inet static
address 192.168.1.111
netmask 255.255.255.0
gateway 192.168.1.1
broadcast 192.168.1.255
dns-nameservers 8.8.8.8 8.8.4.4

Hope this helps.

Allen

On 07/12/2019 17:35, Allen Edwards wrote:
> Here is the solution.
>
> dad@NewMyth:~$ more /etc/network/interfaces
> # interfaces(5) file used by ifup(8) and ifdown(8)
> auto lo
> iface lo inet loopback
> auto enp2s0
> iface enp2s0 inet static
>     address 192.168.1.111
>     netmask 255.255.255.0
>     gateway 192.168.1.1
>     broadcast 192.168.1.255
>     dns-nameservers 8.8.8.8   8.8.4.4

Trying to decode this. I assume that the reason SD made this suggestion,
and that you report it worked for you, is that the creation of an enp2s0
entry in /etc/network/interfaces caused your backend's enp2s0 interface
no longer to be managed by the scourge that is Network Manager (scourge
on servers, not on clients).

So that should be the advice given to others: create an appropriate
entry for your backend's main ethernet interface in its
/etc/network/interfaces file. The above is just an example of what such
an entry might look like. Don't just copy it onto your backend and
assume it will work as-is; you will need to adapt it to your network and
interface name.

(Also, I would steer clear of Google's DNS servers because I value my
privacy, but that's just me).
_______________________________________________
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

On Sat, Dec 7, 2019 at 9:29 AM Jan Ceuleers <jan.ceuleers@gmail.com> wrote:

> On 07/12/2019 17:35, Allen Edwards wrote:
> > Here is the solution.
> >
> > dad@NewMyth:~$ more /etc/network/interfaces
> > # interfaces(5) file used by ifup(8) and ifdown(8)
> > auto lo
> > iface lo inet loopback
> > auto enp2s0
> > iface enp2s0 inet static
> > address 192.168.1.111
> > netmask 255.255.255.0
> > gateway 192.168.1.1
> > broadcast 192.168.1.255
> > dns-nameservers 8.8.8.8 8.8.4.4
>
> Trying to decode this. I assume that the reason SD made this suggestion,
> and that you report it worked for you, is that the creation of an enp2s0
> entry in /etc/network/interfaces caused your backend's enp2s0 interface
> no longer to be managed by the scourge that is Network Manager (scourge
> on servers, not on clients).
>
> So that should be the advice given to others: create an appropriate
> entry for your backend's main ethernet interface in its
> /etc/network/interfaces file. The above is just an example of what such
> an entry might look like. Don't just copy it onto your backend and
> assume it will work as-is; you will need to adapt it to your network and
> interface name.
>
> (Also, I would steer clear of Google's DNS servers because I value my
> privacy, but that's just me).
>
> I honestly do not recall who gave me the suggestions but I think it was on
this group but it could have been through Googling or a mixture. You are
right that it needs to be customized. This is just what I did. It kept the
HDHR connected where previously Linux was disconnecting. The HDHRs were
working fine and I could view them from Windows when the Linux box and thus
Myth could not. What SD did was suggest I use Windows to see if the HDHRs
were still connected and working at a time when Linux could not see them.
It was a great troubleshooting technique as it isolated the problem to
Linux. Not Myth, not the HDHRs.

My son works at Google and I trust them. Let me simplify the privacy issues
and what I understand Google does and does not do.
Google is in the business of selling ads and wants them to be relevant to
the viewer. There are three ways this can be done:
1) By where you are. This is similar to a newspaper having different
editions for different geographies.
2) By what you do. You visited Homedepot.com looked at lawn mowers so here
is a lawn mower ad.
3) By who you are. You are Frank and you like sex, drugs, and rock-n-roll.

Google does 1 and 2 but not 3. In California, starting next year, you can
opt out of #2. I have opted out of #2 on behalf of all my users on my
website for example so I don't need to ask everyone individually. Nice
feature. I think the EU is similar.

It is my belief that Facebook uses #3 and I do not put Google and Facebook
in the same box.

Allen

I really appreciate all the replies and debate, but what I'd rather do,
since I use one combined FE/BE with no other FE's is swap my HDHRs for a
couple single tuner cards, preferably PCIe, I have two open slots, find
them simpler to use, and they suit my use case well, I'm using a Hauppauge
1250 and a pair of Pinnacle PCTV 800i cards. Please contact off list if
you're interested.

On Sat, Dec 7, 2019 at 12:52 PM Allen Edwards <allen.p.edwards@gmail.com>
wrote:

>
>
> On Sat, Dec 7, 2019 at 9:29 AM Jan Ceuleers <jan.ceuleers@gmail.com>
> wrote:
>
>> On 07/12/2019 17:35, Allen Edwards wrote:
>> > Here is the solution.
>> >
>> > dad@NewMyth:~$ more /etc/network/interfaces
>> > # interfaces(5) file used by ifup(8) and ifdown(8)
>> > auto lo
>> > iface lo inet loopback
>> > auto enp2s0
>> > iface enp2s0 inet static
>> > address 192.168.1.111
>> > netmask 255.255.255.0
>> > gateway 192.168.1.1
>> > broadcast 192.168.1.255
>> > dns-nameservers 8.8.8.8 8.8.4.4
>>
>> Trying to decode this. I assume that the reason SD made this suggestion,
>> and that you report it worked for you, is that the creation of an enp2s0
>> entry in /etc/network/interfaces caused your backend's enp2s0 interface
>> no longer to be managed by the scourge that is Network Manager (scourge
>> on servers, not on clients).
>>
>> So that should be the advice given to others: create an appropriate
>> entry for your backend's main ethernet interface in its
>> /etc/network/interfaces file. The above is just an example of what such
>> an entry might look like. Don't just copy it onto your backend and
>> assume it will work as-is; you will need to adapt it to your network and
>> interface name.
>>
>> (Also, I would steer clear of Google's DNS servers because I value my
>> privacy, but that's just me).
>>
>> I honestly do not recall who gave me the suggestions but I think it was
> on this group but it could have been through Googling or a mixture. You are
> right that it needs to be customized. This is just what I did. It kept the
> HDHR connected where previously Linux was disconnecting. The HDHRs were
> working fine and I could view them from Windows when the Linux box and thus
> Myth could not. What SD did was suggest I use Windows to see if the HDHRs
> were still connected and working at a time when Linux could not see them.
> It was a great troubleshooting technique as it isolated the problem to
> Linux. Not Myth, not the HDHRs.
>
> My son works at Google and I trust them. Let me simplify the privacy
> issues and what I understand Google does and does not do.
> Google is in the business of selling ads and wants them to be relevant to
> the viewer. There are three ways this can be done:
> 1) By where you are. This is similar to a newspaper having different
> editions for different geographies.
> 2) By what you do. You visited Homedepot.com looked at lawn mowers so here
> is a lawn mower ad.
> 3) By who you are. You are Frank and you like sex, drugs, and rock-n-roll.
>
> Google does 1 and 2 but not 3. In California, starting next year, you can
> opt out of #2. I have opted out of #2 on behalf of all my users on my
> website for example so I don't need to ask everyone individually. Nice
> feature. I think the EU is similar.
>
> It is my belief that Facebook uses #3 and I do not put Google and Facebook
> in the same box.
>
> Allen
> _______________________________________________
> 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
>

On Sat, Dec 7, 2019 at 10:53 AM Daryl McDonald <darylangela@gmail.com>
wrote:

> I really appreciate all the replies and debate, but what I'd rather do,
> since I use one combined FE/BE with no other FE's is swap my HDHRs for a
> couple single tuner cards, preferably PCIe, I have two open slots, find
> them simpler to use, and they suit my use case well, I'm using a Hauppauge
> 1250 and a pair of Pinnacle PCTV 800i cards. Please contact off list if
> you're interested.
>
> On Sat, Dec 7, 2019 at 12:52 PM Allen Edwards <allen.p.edwards@gmail.com>
> wrote:
>
>>
>>
>> On Sat, Dec 7, 2019 at 9:29 AM Jan Ceuleers <jan.ceuleers@gmail.com>
>> wrote:
>>
>>> On 07/12/2019 17:35, Allen Edwards wrote:
>>> > Here is the solution.
>>> >
>>> > dad@NewMyth:~$ more /etc/network/interfaces
>>> > # interfaces(5) file used by ifup(8) and ifdown(8)
>>> > auto lo
>>> > iface lo inet loopback
>>> > auto enp2s0
>>> > iface enp2s0 inet static
>>> > address 192.168.1.111
>>> > netmask 255.255.255.0
>>> > gateway 192.168.1.1
>>> > broadcast 192.168.1.255
>>> > dns-nameservers 8.8.8.8 8.8.4.4
>>>
>>> Trying to decode this. I assume that the reason SD made this suggestion,
>>> and that you report it worked for you, is that the creation of an enp2s0
>>> entry in /etc/network/interfaces caused your backend's enp2s0 interface
>>> no longer to be managed by the scourge that is Network Manager (scourge
>>> on servers, not on clients).
>>>
>>> So that should be the advice given to others: create an appropriate
>>> entry for your backend's main ethernet interface in its
>>> /etc/network/interfaces file. The above is just an example of what such
>>> an entry might look like. Don't just copy it onto your backend and
>>> assume it will work as-is; you will need to adapt it to your network and
>>> interface name.
>>>
>>> (Also, I would steer clear of Google's DNS servers because I value my
>>> privacy, but that's just me).
>>>
>>> I honestly do not recall who gave me the suggestions but I think it was
>> on this group but it could have been through Googling or a mixture. You are
>> right that it needs to be customized. This is just what I did. It kept the
>> HDHR connected where previously Linux was disconnecting. The HDHRs were
>> working fine and I could view them from Windows when the Linux box and thus
>> Myth could not. What SD did was suggest I use Windows to see if the HDHRs
>> were still connected and working at a time when Linux could not see them.
>> It was a great troubleshooting technique as it isolated the problem to
>> Linux. Not Myth, not the HDHRs.
>>
>> My son works at Google and I trust them. Let me simplify the privacy
>> issues and what I understand Google does and does not do.
>> Google is in the business of selling ads and wants them to be relevant to
>> the viewer. There are three ways this can be done:
>> 1) By where you are. This is similar to a newspaper having different
>> editions for different geographies.
>> 2) By what you do. You visited Homedepot.com looked at lawn mowers so
>> here is a lawn mower ad.
>> 3) By who you are. You are Frank and you like sex, drugs, and rock-n-roll.
>>
>> Google does 1 and 2 but not 3. In California, starting next year, you can
>> opt out of #2. I have opted out of #2 on behalf of all my users on my
>> website for example so I don't need to ask everyone individually. Nice
>> feature. I think the EU is similar.
>>
>> It is my belief that Facebook uses #3 and I do not put Google and
>> Facebook in the same box.
>>
>> Allen
>>
>
I went the other way. Took out my internal tuner cards and used the HDHR.
So long ago I can't remember all the reasons but I know internal heat in
the computer case was one. I liked it so much I bought a second one on
Craigslist, which is how I got the underrated wall wart that ended up
giving me problems. My tuner cards are a decade old so probably not worth
using but I can go look if you are interested.

Allen

On Sat, Dec 7, 2019 at 10:39 AM Stephen Worthington <
stephen_agent@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@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.

yes, very interested, what do you have?

On Sat, Dec 7, 2019 at 2:27 PM Allen Edwards <allen.p.edwards@gmail.com>
wrote:

>
>
> On Sat, Dec 7, 2019 at 10:53 AM Daryl McDonald <darylangela@gmail.com>
> wrote:
>
>> I really appreciate all the replies and debate, but what I'd rather do,
>> since I use one combined FE/BE with no other FE's is swap my HDHRs for a
>> couple single tuner cards, preferably PCIe, I have two open slots, find
>> them simpler to use, and they suit my use case well, I'm using a Hauppauge
>> 1250 and a pair of Pinnacle PCTV 800i cards. Please contact off list if
>> you're interested.
>>
>> On Sat, Dec 7, 2019 at 12:52 PM Allen Edwards <allen.p.edwards@gmail.com>
>> wrote:
>>
>>>
>>>
>>> On Sat, Dec 7, 2019 at 9:29 AM Jan Ceuleers <jan.ceuleers@gmail.com>
>>> wrote:
>>>
>>>> On 07/12/2019 17:35, Allen Edwards wrote:
>>>> > Here is the solution.
>>>> >
>>>> > dad@NewMyth:~$ more /etc/network/interfaces
>>>> > # interfaces(5) file used by ifup(8) and ifdown(8)
>>>> > auto lo
>>>> > iface lo inet loopback
>>>> > auto enp2s0
>>>> > iface enp2s0 inet static
>>>> > address 192.168.1.111
>>>> > netmask 255.255.255.0
>>>> > gateway 192.168.1.1
>>>> > broadcast 192.168.1.255
>>>> > dns-nameservers 8.8.8.8 8.8.4.4
>>>>
>>>> Trying to decode this. I assume that the reason SD made this suggestion,
>>>> and that you report it worked for you, is that the creation of an enp2s0
>>>> entry in /etc/network/interfaces caused your backend's enp2s0 interface
>>>> no longer to be managed by the scourge that is Network Manager (scourge
>>>> on servers, not on clients).
>>>>
>>>> So that should be the advice given to others: create an appropriate
>>>> entry for your backend's main ethernet interface in its
>>>> /etc/network/interfaces file. The above is just an example of what such
>>>> an entry might look like. Don't just copy it onto your backend and
>>>> assume it will work as-is; you will need to adapt it to your network and
>>>> interface name.
>>>>
>>>> (Also, I would steer clear of Google's DNS servers because I value my
>>>> privacy, but that's just me).
>>>>
>>>> I honestly do not recall who gave me the suggestions but I think it was
>>> on this group but it could have been through Googling or a mixture. You are
>>> right that it needs to be customized. This is just what I did. It kept the
>>> HDHR connected where previously Linux was disconnecting. The HDHRs were
>>> working fine and I could view them from Windows when the Linux box and thus
>>> Myth could not. What SD did was suggest I use Windows to see if the HDHRs
>>> were still connected and working at a time when Linux could not see them.
>>> It was a great troubleshooting technique as it isolated the problem to
>>> Linux. Not Myth, not the HDHRs.
>>>
>>> My son works at Google and I trust them. Let me simplify the privacy
>>> issues and what I understand Google does and does not do.
>>> Google is in the business of selling ads and wants them to be relevant
>>> to the viewer. There are three ways this can be done:
>>> 1) By where you are. This is similar to a newspaper having different
>>> editions for different geographies.
>>> 2) By what you do. You visited Homedepot.com looked at lawn mowers so
>>> here is a lawn mower ad.
>>> 3) By who you are. You are Frank and you like sex, drugs, and
>>> rock-n-roll.
>>>
>>> Google does 1 and 2 but not 3. In California, starting next year, you
>>> can opt out of #2. I have opted out of #2 on behalf of all my users on my
>>> website for example so I don't need to ask everyone individually. Nice
>>> feature. I think the EU is similar.
>>>
>>> It is my belief that Facebook uses #3 and I do not put Google and
>>> Facebook in the same box.
>>>
>>> Allen
>>>
>>
> I went the other way. Took out my internal tuner cards and used the HDHR.
> So long ago I can't remember all the reasons but I know internal heat in
> the computer case was one. I liked it so much I bought a second one on
> Craigslist, which is how I got the underrated wall wart that ended up
> giving me problems. My tuner cards are a decade old so probably not worth
> using but I can go look if you are interested.
>
> Allen
> _______________________________________________
> 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
>

On Sat, Dec 7, 2019 at 1:56 AM Stephen Worthington <stephen_agent@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@mythtv.org
> http://lists.mythtv.org/mailman/listinfo/mythtv-users
> http://wiki.mythtv.org/Mailing_List_etiquette
> MythTV Forums: https://forum.mythtv.org
>

One after thought Allen, I can't use an analog tuner it myust be digital,
thanks

On Sat, Dec 7, 2019 at 2:29 PM Daryl McDonald <darylangela@gmail.com> wrote:

> yes, very interested, what do you have?
>
> On Sat, Dec 7, 2019 at 2:27 PM Allen Edwards <allen.p.edwards@gmail.com>
> wrote:
>
>>
>>
>> On Sat, Dec 7, 2019 at 10:53 AM Daryl McDonald <darylangela@gmail.com>
>> wrote:
>>
>>> I really appreciate all the replies and debate, but what I'd rather do,
>>> since I use one combined FE/BE with no other FE's is swap my HDHRs for a
>>> couple single tuner cards, preferably PCIe, I have two open slots, find
>>> them simpler to use, and they suit my use case well, I'm using a Hauppauge
>>> 1250 and a pair of Pinnacle PCTV 800i cards. Please contact off list if
>>> you're interested.
>>>
>>> On Sat, Dec 7, 2019 at 12:52 PM Allen Edwards <allen.p.edwards@gmail.com>
>>> wrote:
>>>
>>>>
>>>>
>>>> On Sat, Dec 7, 2019 at 9:29 AM Jan Ceuleers <jan.ceuleers@gmail.com>
>>>> wrote:
>>>>
>>>>> On 07/12/2019 17:35, Allen Edwards wrote:
>>>>> > Here is the solution.
>>>>> >
>>>>> > dad@NewMyth:~$ more /etc/network/interfaces
>>>>> > # interfaces(5) file used by ifup(8) and ifdown(8)
>>>>> > auto lo
>>>>> > iface lo inet loopback
>>>>> > auto enp2s0
>>>>> > iface enp2s0 inet static
>>>>> > address 192.168.1.111
>>>>> > netmask 255.255.255.0
>>>>> > gateway 192.168.1.1
>>>>> > broadcast 192.168.1.255
>>>>> > dns-nameservers 8.8.8.8 8.8.4.4
>>>>>
>>>>> Trying to decode this. I assume that the reason SD made this
>>>>> suggestion,
>>>>> and that you report it worked for you, is that the creation of an
>>>>> enp2s0
>>>>> entry in /etc/network/interfaces caused your backend's enp2s0 interface
>>>>> no longer to be managed by the scourge that is Network Manager (scourge
>>>>> on servers, not on clients).
>>>>>
>>>>> So that should be the advice given to others: create an appropriate
>>>>> entry for your backend's main ethernet interface in its
>>>>> /etc/network/interfaces file. The above is just an example of what such
>>>>> an entry might look like. Don't just copy it onto your backend and
>>>>> assume it will work as-is; you will need to adapt it to your network
>>>>> and
>>>>> interface name.
>>>>>
>>>>> (Also, I would steer clear of Google's DNS servers because I value my
>>>>> privacy, but that's just me).
>>>>>
>>>>> I honestly do not recall who gave me the suggestions but I think it
>>>> was on this group but it could have been through Googling or a mixture. You
>>>> are right that it needs to be customized. This is just what I did. It kept
>>>> the HDHR connected where previously Linux was disconnecting. The HDHRs were
>>>> working fine and I could view them from Windows when the Linux box and thus
>>>> Myth could not. What SD did was suggest I use Windows to see if the HDHRs
>>>> were still connected and working at a time when Linux could not see them.
>>>> It was a great troubleshooting technique as it isolated the problem to
>>>> Linux. Not Myth, not the HDHRs.
>>>>
>>>> My son works at Google and I trust them. Let me simplify the privacy
>>>> issues and what I understand Google does and does not do.
>>>> Google is in the business of selling ads and wants them to be relevant
>>>> to the viewer. There are three ways this can be done:
>>>> 1) By where you are. This is similar to a newspaper having different
>>>> editions for different geographies.
>>>> 2) By what you do. You visited Homedepot.com looked at lawn mowers so
>>>> here is a lawn mower ad.
>>>> 3) By who you are. You are Frank and you like sex, drugs, and
>>>> rock-n-roll.
>>>>
>>>> Google does 1 and 2 but not 3. In California, starting next year, you
>>>> can opt out of #2. I have opted out of #2 on behalf of all my users on my
>>>> website for example so I don't need to ask everyone individually. Nice
>>>> feature. I think the EU is similar.
>>>>
>>>> It is my belief that Facebook uses #3 and I do not put Google and
>>>> Facebook in the same box.
>>>>
>>>> Allen
>>>>
>>>
>> I went the other way. Took out my internal tuner cards and used the
>> HDHR. So long ago I can't remember all the reasons but I know internal
>> heat in the computer case was one. I liked it so much I bought a second one
>> on Craigslist, which is how I got the underrated wall wart that ended up
>> giving me problems. My tuner cards are a decade old so probably not worth
>> using but I can go look if you are interested.
>>
>> Allen
>> _______________________________________________
>> 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
>>
>

On Sat, Dec 7, 2019 at 11:57 AM Daryl McDonald <darylangela@gmail.com>
wrote:

> One after thought Allen, I can't use an analog tuner it myust be digital,
> thanks
> mythtv.org <https://forum.mythtv.org>


https://linuxtv.org/wiki/index.php/TechniSat_Air2PC-ATSC-PCI rev 1.

I guess the reason for my post was to talk you out of using cards like I
did. I would bet that newer cards are much better as this card is old but
the HDHR units work flawlessly once you set them up. Of course, I also use
the optical feature for my remote. That may have been a factor in my
switch. I have two HDHR original dual boxes. No complaints.

Allen

On Sat, Dec 7, 2019 at 3:59 PM Allen Edwards <allen.p.edwards@gmail.com>
wrote:

>
>
> On Sat, Dec 7, 2019 at 11:57 AM Daryl McDonald <darylangela@gmail.com>
> wrote:
>
>> One after thought Allen, I can't use an analog tuner it myust be digital,
>> thanks
>> mythtv.org <https://forum.mythtv.org>
>
>
> https://linuxtv.org/wiki/index.php/TechniSat_Air2PC-ATSC-PCI rev 1.
>
> I guess the reason for my post was to talk you out of using cards like I
> did. I would bet that newer cards are much better as this card is old but
> the HDHR units work flawlessly once you set them up. Of course, I also use
> the optical feature for my remote. That may have been a factor in my
> switch. I have two HDHR original dual boxes. No complaints.
>
> Allen
> _______________________________________________
> 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



https://www.amazon.ca/Ziyituod-Network-Ethernet-Gigabit-1000Mbps/dp/B07T55GSF9/ref=sr_1_4?keywords=NIC&qid=1575756626&sr=8-4&th=1

Would one of these network cards allow me to connect both HDHRs directly to
the PC and avouid network traffic issues?

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




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.


Don't know if this is helpful or outdated but did a search on HDHomerun and
DSCP and this came up:

http://mythtvblog.blogspot.com/2008/03/enabling-quality-of-service-for.html?m=1

On Sat, 7 Dec 2019 18:21:44 -0500, you wrote:

>On Sat, Dec 7, 2019, 10:40 AM Stephen Worthington, <stephen_agent@jsw.gen.nz>
>wrote:
>
>
>
>
>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.
>
>
>Don't know if this is helpful or outdated but did a search on HDHomerun and
>DSCP and this came up:
>
>http://mythtvblog.blogspot.com/2008/03/enabling-quality-of-service-for.html?m=1

Using that method of doing QoS looks like it would work, but is pretty
painful as it requires a patch to MythTV and using VLANs. I would
hope that by now the HDHR firmware would support using the DSCP bit in
the IP headers, and do it as a default (not needing to be enabled in
the URL that starts a recording). That would make it much easier to
use.

So is there anyone who is using an HDHR with the latest firmware who
would be able to do a capture of the packets and take a look at the
DSCP bits? Or post a capture file somewhere for me to download?
_______________________________________________
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

On Sat, 7 Dec 2019 14:47:30 -0500, you wrote:

>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) ?

Yes, that is the way to do it. You do need to reboot afterwards for
that command to take effect. I have never tried this, but it should
shut down the debug shell immediately if you do this:

sudo systemctl stop debug-shell.service

which would avoid the need for a reboot. Test to make sure it worked
by doing Ctrl-Alt-F9. There should no longer be any response from the
shell that was running there. You would still need to do the
systemctl disable command or the debug shell would be back at the next
reboot.

If you have never used things like Ctrl-Alt-F9 before, you need to
remember that Ctrl-Alt-F7 will get you back to the GUI screen. During
shut down, the GUI goes away fairly early, so when trying to debug
shutdown problems, if Ctrl-Alt-F7 does not work, that is not a problem
as all it means is the GUI got shut down normally. Just do
Ctrl-Alt-F9 to get back to the debug shell again.
_______________________________________________
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

>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.
>
> Hi,

Nick here from SIlicondust...

All HDHomeRun models tag UDP and RTP video stream packets with IP_TOS =
(5<<5). No target option required.

After reviewing I see two possible quirks...
1) Wireshark is reporting that as CS5 whereas I think it should be CS3 for
broadcast video.
2) The HDHomeRun should probably tag HTTP video stream packets with CS3 as
well.

Nick

On Sat, Dec 7, 2019 at 7:56 PM Silicondust <mythtv@silicondust.com> wrote:

> >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.
>>
>> All HDHomeRun models tag UDP and RTP video stream packets with IP_TOS =
> (5<<5). No target option required.
>
> After reviewing I see two possible quirks...
> 1) Wireshark is reporting that as CS5 whereas I think it should be CS3 for
> broadcast video.
> 2) The HDHomeRun should probably tag HTTP video stream packets with CS3 as
> well.
>
> Correction - all HDHomeRun models tag UDP, RTP, and HTTP video stream
packets with CS5 today.
The only question is if it should be CS3 rather than CS5.

On Sat, 7 Dec 2019 14:28:42 -0500, you wrote:

>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.

So that makes it unlikely that it was a traffic problem that caused
the bad recordings.

When you say "failed", what exactly happened? Did the recordings just
stop, or did they complete but had lots of errors?

>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?

I am presuming that you have your MythTV box and HDHRs all connected
to the same "smart switch" and on the same subnet. If so, then the
packets between the HDHRs and the MythTV box will never be going to
the router, and will not be affected by its QoS operations. The
packets will be switched by the Ethernet switch between its ports
without ever getting to the router.

Ideally, you would want your switch to do DSCP QoS, but it is unlikely
it is capable of that. QoS in switches is usually only found in
enterprise grade switches or top end consumer ones. But you certainly
should look up your switch to see if it is capable of doing DSCP QoS.

I have an EdgeSwitch ES-24-LITE:

https://www.ui.com/edgemax/edgeswitch-lite/

which is an enterprise grade switch and has full QoS capabilities.
That is one of the features I bought it for. I have it configured to
do DSCP priority on all ports, but I have never actually tested to see
if it is working as I do not have any problems that would actually
need DSCP to be working.
_______________________________________________
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

On Sat, Dec 7, 2019 at 8:17 PM Stephen Worthington <stephen_agent@jsw.gen.nz>
wrote:

> On Sat, 7 Dec 2019 14:28:42 -0500, you wrote:
>
> >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.
>
> So that makes it unlikely that it was a traffic problem that caused
> the bad recordings.
>
> When you say "failed", what exactly happened? Did the recordings just
> stop, or did they complete but had lots of errors?
>
> >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?
>
> I am presuming that you have your MythTV box and HDHRs all connected
> to the same "smart switch" and on the same subnet. If so, then the
> packets between the HDHRs and the MythTV box will never be going to
> the router, and will not be affected by its QoS operations. The
> packets will be switched by the Ethernet switch between its ports
> without ever getting to the router.
>
> Ideally, you would want your switch to do DSCP QoS, but it is unlikely
> it is capable of that. QoS in switches is usually only found in
> enterprise grade switches or top end consumer ones. But you certainly
> should look up your switch to see if it is capable of doing DSCP QoS.
>
> I have an EdgeSwitch ES-24-LITE:
>
> https://www.ui.com/edgemax/edgeswitch-lite/
>
> which is an enterprise grade switch and has full QoS capabilities.
> That is one of the features I bought it for. I have it configured to
> do DSCP priority on all ports, but I have never actually tested to see
> if it is working as I do not have any problems that would actually
> need DSCP to be working.
> _______________________________________________
>
>
I use a Cisco-Linksys EZXS55W EtherFast 10/100 5-Port Workgroup Switch.
It has two HDHR and the Myth computer into it as well as the line going to
my R6700 Nighthawk router.
No problems whatsoever since I made the changes to the Linux configuration.

Allen

On Sat, 7 Dec 2019 20:08:35 -0700, you wrote:

>On Sat, Dec 7, 2019 at 7:56 PM Silicondust <mythtv@silicondust.com> wrote:
>
>> >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.
>>>
>>> All HDHomeRun models tag UDP and RTP video stream packets with IP_TOS =
>> (5<<5). No target option required.
>>
>> After reviewing I see two possible quirks...
>> 1) Wireshark is reporting that as CS5 whereas I think it should be CS3 for
>> broadcast video.
>> 2) The HDHomeRun should probably tag HTTP video stream packets with CS3 as
>> well.
>>
>> Correction - all HDHomeRun models tag UDP, RTP, and HTTP video stream
>packets with CS5 today.
>The only question is if it should be CS3 rather than CS5.

Excellent!

As for CS3 versus CS5, there are two different ways an HDHR gets used.
One is where it is being recorded, and the other is where it is being
watched directly by a human. For a recording, it would actually be
better to use a TCP connection with error correction and
retransmission, so you could under most circumstances ensure that
there were zero lost or damaged packets. It does not matter to a
recording device if the packets arrive a little late and with variable
timing. So if a TCP connection is used, in theory it would not be
necessary to use a DSCP priority tag at all. Where a human is
watching though, the error correction involved in a TCP connection is
usually unacceptable as it causes "buffering" moments where the
playback stops. So for a human, a high priority for the traffic is
necessary to allow the packets to not be dropped and to travel with
low jitter. So that might well justify using CS5 instead of the CS3
recommended by RFC4594. For recording using UDP packets, CS3 should
be all that is necessary.

So if I had to pick between CS3 and CS5 on all the packets, I would go
with CS5 until there was some way for the HDHR to know whether a human
was watching or it was being used for recording purposes.
_______________________________________________
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

On Sat, 7 Dec 2019 17:22:00 -0500, you wrote:

>On Sat, Dec 7, 2019 at 3:59 PM Allen Edwards <allen.p.edwards@gmail.com>
>wrote:
>
>>
>>
>> On Sat, Dec 7, 2019 at 11:57 AM Daryl McDonald <darylangela@gmail.com>
>> wrote:
>>
>>> One after thought Allen, I can't use an analog tuner it myust be digital,
>>> thanks
>>> mythtv.org <https://forum.mythtv.org>
>>
>>
>> https://linuxtv.org/wiki/index.php/TechniSat_Air2PC-ATSC-PCI rev 1.
>>
>> I guess the reason for my post was to talk you out of using cards like I
>> did. I would bet that newer cards are much better as this card is old but
>> the HDHR units work flawlessly once you set them up. Of course, I also use
>> the optical feature for my remote. That may have been a factor in my
>> switch. I have two HDHR original dual boxes. No complaints.
>>
>> Allen
>
>
>https://www.amazon.ca/Ziyituod-Network-Ethernet-Gigabit-1000Mbps/dp/B07T55GSF9/ref=sr_1_4?keywords=NIC&qid=1575756626&sr=8-4&th=1
>
>Would one of these network cards allow me to connect both HDHRs directly to
>the PC and avouid network traffic issues?

Yes, that should do the job. In the past, I have had problems with
the RealTek 8111 drivers, but the current driver in Ubuntu 18.04 seems
fine.

You will likely need to set up the two new Ethernet ports with static
IP addresses as they will not be on the network that your router is on
and will therefore not have DHCP addressing available as that is done
by the router normally. You can do that with the NetworkManager GUI
these days, rather than having to use the /etc/network/interfaces
file. NetworkManager in 18.04 is actually quite useable now. Make
sure that you use different subnets from the one(s) in use on your
network already. So if you are already using 192.168.1.0/24 for
example, you might use 192.168.100.0/24 and 192.168.101.0/24 for the
two subnets on the new Ethernet ports, and assign the ports the static
IPs of (for example) 192.168.100.254 and 192.168.101.254 respectively.

I use a numbering convention in my network where I put network/server
devices on the high numbers of the subnet and clients on the low
numbers, hence my suggestion to use x.x.x.254 for the new Ethernet
ports. Your convention (if you have one) may differ.

If you are planning on adding, moving or removing cards in that PC at
a later date, be aware that you can find that the names of the
Ethernet ports will change if you do that. I prefer to avoid that by
using udev to lock down the Ethernet ports, and at the same time
change them back to the old eth0, eth1, ... names. To do that, you
install the Ethernet card and boot up, then run "ifconfig" to find the
MAC addresses of all your Ethernet ports. This is what I get for one
of my Ethernet ports:

eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 10.0.2.12 netmask 255.255.255.0 broadcast 10.0.2.255
inet6 2406:e001:1:2802::1 prefixlen 64 scopeid 0x0<global>
inet6 fe80::ad6d:51:db52:2fe1 prefixlen 64 scopeid
0x20<link>
inet6 2406:e001:1:2802::12 prefixlen 64 scopeid 0x0<global>
ether 00:1f:c6:24:64:ce txqueuelen 1000 (Ethernet)
RX packets 20960054 bytes 10560820118 (10.5 GB)
RX errors 0 dropped 0 overruns 3 frame 3
TX packets 18901618 bytes 28550219983 (28.5 GB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
device interrupt 17

The MAC address is the "00:1f:c6:24:64:ce" after the word "ether" on
the 6th line in that example. You put the MAC address in a line in a
config file in /etc/udev/rules.d that looks like this from my "lith"
box:

root@lith:/var/log# cat /etc/udev/rules.d/20-network.rules
# Asus P5K-E motherboard
SUBSYSTEM=="net", ACTION=="add", ATTR{address}=="00:1f:c6:24:64:ce",
NAME="eth0"

# Intel Pro/1000 MT Desktop Ethernet adapter (PCI)
SUBSYSTEM=="net", ACTION=="add", ATTR{address}=="00:07:e9:11:c5:95",
NAME="eth1"

The MAC address goes in the ATTR{address}=="<MAC address>" clause and
you can put whatever you prefer for the NAME. Then reboot.

The 20-network.rules file can be any name you like as long as it has a
.rules extension. The convention is to use numbers on the front to
control the order the udev rules are executed. The file should be
chown root:root and chmod u=rw,g=r,o=r.

However, there is a serious problem that I did realise about using a
separate network for HDHRs. It appears that HDHRs have no way to be
set up with a static IP address - they always need DHCP. I can see
the reason for that, but in this situation it is a pain as you would
then need to set up DHCP servers for each of the two new Ethernet
ports. In Ubuntu 18.04 with the way Ubuntu are using parts of various
different network software such as systemd-resolved and dnsmasq, I am
not sure how to go about setting up a DHCP server on those two ports.
It might be as simple as installing the ISC DHCP server package and
configuring it, or that might conflict with the dnsmasq's ability to
be a DHCP server. I will have to try it out and report back.
_______________________________________________
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

On 08/12/2019 07:40, Stephen Worthington wrote:
> As for CS3 versus CS5, there are two different ways an HDHR gets used.
> One is where it is being recorded, and the other is where it is being
> watched directly by a human. For a recording, it would actually be
> better to use a TCP connection with error correction and
> retransmission, so you could under most circumstances ensure that
> there were zero lost or damaged packets. It does not matter to a
> recording device if the packets arrive a little late and with variable
> timing. So if a TCP connection is used, in theory it would not be
> necessary to use a DSCP priority tag at all. Where a human is
> watching though, the error correction involved in a TCP connection is
> usually unacceptable as it causes "buffering" moments where the
> playback stops. So for a human, a high priority for the traffic is
> necessary to allow the packets to not be dropped and to travel with
> low jitter. So that might well justify using CS5 instead of the CS3
> recommended by RFC4594. For recording using UDP packets, CS3 should
> be all that is necessary.

Stephen, I am wondering about circumstances under which packet drops
would occur in a home network at all. Furthermore I am wondering whether
you'd have an intelligent device in a home network making decisions
about which packets to drop, or whether any such packet dropping would
be done by consumer-class boxes that lack the smarts to look at packet
classification.

The topic you describe is relevant in an enterprise network, but in a
home network?

The only in-home scenario I can think of is WiFi APs, given that WMM has
been a mandatory feature of the standards for some time now. Still, it
seems that the mapping of DSCP values to WMM access categories is
inconsistent across WiFi vendor implementations, so not very useful in
practice.

Cheers, Jan
_______________________________________________
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

On Sun, 8 Dec 2019 08:46:20 +0100, you wrote:

>On 08/12/2019 07:40, Stephen Worthington wrote:
>> As for CS3 versus CS5, there are two different ways an HDHR gets used.
>> One is where it is being recorded, and the other is where it is being
>> watched directly by a human. For a recording, it would actually be
>> better to use a TCP connection with error correction and
>> retransmission, so you could under most circumstances ensure that
>> there were zero lost or damaged packets. It does not matter to a
>> recording device if the packets arrive a little late and with variable
>> timing. So if a TCP connection is used, in theory it would not be
>> necessary to use a DSCP priority tag at all. Where a human is
>> watching though, the error correction involved in a TCP connection is
>> usually unacceptable as it causes "buffering" moments where the
>> playback stops. So for a human, a high priority for the traffic is
>> necessary to allow the packets to not be dropped and to travel with
>> low jitter. So that might well justify using CS5 instead of the CS3
>> recommended by RFC4594. For recording using UDP packets, CS3 should
>> be all that is necessary.
>
>Stephen, I am wondering about circumstances under which packet drops
>would occur in a home network at all. Furthermore I am wondering whether
>you'd have an intelligent device in a home network making decisions
>about which packets to drop, or whether any such packet dropping would
>be done by consumer-class boxes that lack the smarts to look at packet
>classification.
>
>The topic you describe is relevant in an enterprise network, but in a
>home network?
>
>The only in-home scenario I can think of is WiFi APs, given that WMM has
>been a mandatory feature of the standards for some time now. Still, it
>seems that the mapping of DSCP values to WMM access categories is
>inconsistent across WiFi vendor implementations, so not very useful in
>practice.

There did not used to be any common situations where a 1 gigabit
Ethernet connection in a home network could be flooded and cause
packet drops. But that changed when hard drives became available that
could read and write faster than 1 gigabit/s, and it got worse when
SSDs came along as they are all much faster than that. So now a
simple file copy across a network connection can use up the entire 1
gigabit/s easily. That does not cause problems with TCP traffic - a
packet drop with TCP simply causes a resend and usually will also slow
down the TCP traffic, preventing further packet drops for a while. But
with UDP you can get packet drops that cause problems, especially with
multimedia streams. And it is dead easy for someone (or the system)
to start heavy traffic like that at any time.

For quite a while now, Linux systems have by default set up traffic
control on the transmit side of Ethernet ports. If you do a command
like this:

root@mypvr:~# ip link show eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel
master br0 state UP mode DEFAULT group default qlen 1000
link/ether c8:60:00:15:81:76 brd ff:ff:ff:ff:ff:ff

you will see "qdisc fq_codel" which tells you that the "Queuing
Discipline" is set to "Fair Queuing with Controlled Delay". The "qlen
1000" is the size of the transmit queue. So packets being sent via
eth0 will be queued and then sent in the order decided by the fq_codel
algorithm, or dropped as necessary. The command "tc" (Traffic
Control) allows you to set up all the parameters for this, but the
default setup is usually all that is needed for a home network.

A command like this:

root@mypvr:~# tc -s qdisc show dev eth0
qdisc fq_codel 0: root refcnt 2 limit 10240p flows 1024 quantum 1514
target 5.0ms interval 100.0ms memory_limit 32Mb ecn
Sent 15430762721 bytes 14388768 pkt (dropped 0, overlimits 0 requeues
14)
backlog 0b 0p requeues 14
maxpacket 65102 drop_overlimit 0 new_flow_count 11282 ecn_mark 0
new_flows_len 0 old_flows_len 0

can show you what the traffic control has been doing. I have no idea
what "requeues 14" means, but "dropped 0" looks good to me.

The problem with network tuners unfortunately is on the receive side
for a MythTV box - where the MythTV box does not have any control. All
the receiving Ethernet port can do is receive the packets sent to it.
Packet dropping happens at the transmit end, or in between. In the
case of network tuners connected via an Ethernet switch, it will
normally be the switch that has to drop excess packets, as the
connection from the tuner to the switch is full speed without any
contention from other traffic, there being only one device on the
switch's Ethernet port. And home user type switches rarely have any
control on how contention is handled, although they may use a sensible
algorithm. It just depends on how they are designed and what their
silicon is capable of. You would hope that by now the silicon would
be able to check the DSCP bits and drop lower priority packets when Tx
port queue on the switch overflows, but I have never seen any
datasheet or manual for a home type switch that told you anything
about that. On cheap switches, it may simply work by FIFO and any
packet that gets queued for transmission on a switch port when that
queue is full will simply be dropped.
_______________________________________________
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

On 08/12/2019 10:39, Stephen Worthington wrote:
> There did not used to be any common situations where a 1 gigabit
> Ethernet connection in a home network could be flooded and cause
> packet drops. But that changed when hard drives became available that
> could read and write faster than 1 gigabit/s, and it got worse when
> SSDs came along as they are all much faster than that. So now a

Fair enough, the disks are now faster.

> For quite a while now, Linux systems have by default set up traffic
> control on the transmit side of Ethernet ports.

Well aware of this - I'm on the bufferbloat mailing list.

But the point I was raising is about packet drops within the home
/network/, i.e. not at the endpoints where you can indeed assume that
queuing and differentiated dropping are available. It's the network
elements (i.e. ethernet switches, WiFi routers) that packet marking is
aimed at. Consumer-level devices typically do not support differentiated
treatment of traffic. Not even if they run Linux because the forwarding
is delegated to a hardware packet accelerator which doesn't support many
of the features present in the Linux kernel which apply only to software
forwarding.

> The problem with network tuners unfortunately is on the receive side
> for a MythTV box - where the MythTV box does not have any control. All
> the receiving Ethernet port can do is receive the packets sent to it.
> Packet dropping happens at the transmit end, or in between.

Right.

Since we are talking about HDHRs we can safely say that the dropping
does not happen at the transmit side, since this would point to a design
flaw on the part of SD (namely an underdimensioning of the Ethernet
port). My 4-port HDHR has a 100Mbit/s Ethernet interface which is still
dramatically under-utilised when 4 HD DVB-C recordings are in progress.

So this is about the network in between the tuners and the backend. And
you go on to hope that the silicon used in today's consumer-level
switches supports DSCP these days, and I'm afraid that this is simply
not the case. That was my point.

In practice users will need to design their networks such that there is
no overload on the network path between network tuners on the one hand
and the mythtv backend on the other. The easiest way of doing that is to
connect the network tuner to a separate network interface on the
backend, i.e. not to put the network tuner on the LAN at all. The
second-best approach is to apply ingress traffic shaping to the network
port on the backend such that aggregate ingress traffic from senders
other than the network tuners is capped. This provides backpressure to
incoming TCP flows. Doesn't help against UDP overload. Make sure
therefore that NFS is configured to use TCP rather than UDP, and the
same applies to other protocols that offer a choice of transport.

I don't do any of this because in practice I don't see packet loss on my
machinery. Not even during my weekly backup runs (a couple of which
involve backing up from NVMe SSDs in client devices to a SATA3-connected
spinning rust disk in the server. It could happen if a large file needs
to be transported, but this is mitigated by the amount of RAM the server
uses as a disk buffer.

BR, Jan
_______________________________________________
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

I have tried out setting up isc-dhcp-server on Ubuntu 18.04 to work
with my eth1 card (which I normally do not use except for testing
things like this). It works fine as long as the configuration is done
correctly. Here is the /etc/dhcp/dhcpd.conf file I used for my
testing:

# dhcpd.conf

# option definitions common to all supported networks...
option domain-name "jsw.gen.nz";
option domain-name-servers ns1g.jsw.gen.nz, ns2.jsw.gen.nz;

default-lease-time 600;
max-lease-time 7200;

# The ddns-updates-style parameter controls whether or not the server
will
# attempt to do a DNS update when a lease is confirmed. We default to
the
# behavior of the version 2 packages ('none', since DHCP v2 didn't
# have support for DDNS.)
ddns-update-style none;

# If this DHCP server is the official DHCP server for the local
# network, the authoritative directive should be uncommented.
authoritative;

host gt70 {
hardware ethernet 8c:89:a5:01:24:b5;
fixed-address 192.168.100.14;
}

subnet 192.168.100.0 netmask 255.255.255.0 {
option routers lith.jsw.gen.nz;
pool {
range 192.168.100.100 192.168.100.200;
}
}

First I installed the package:

sudo apt install isc-dhcp-server

Then I told the NetworkManager GUI to give eth1 a fixed IP address of
192.168.100.254, set up the /etc/dhcp/dhcpd.conf file as above,
plugged in my laptop to eth1, told NetworkManager to switch on eth1,
then started the ISC DHCP server:

sudo systemctl start isc-dhcp-server

and it worked and the laptop got the IP address 192.168.100.14.

I also had to do this:

sudo systemctl disable isc-dhcp-server6

as the package also installed the IPv6 DHCP server which was not
wanted for eth1.

So to set up a similar configuration for your dual Ethernet card, you
would want two host{} configurations with the MAC addresses of the two
HDHRs, one with address 192.168.100.1 and the other with the address
192.168.101.1. And add a second subnet{} configuration for the
192.168.101.0/24 subnet. Change all the names and name servers to
what you use in your network. The "option routers" line should have
the IP address of your MythTV backend box. That line is not
sufficient to allow the HDHRs (or anything else you plug into the dual
Ethernet card) to access the Internet - if you needed that, you would
have to enable routing on the backend box and set up its routing
table, and maybe also add routes in your main router for the two
subnets on the dual Ethernet card.

If you boot the backend box when the HDHRs are switched off,
NetworkManager will not enable the Ethernet ports they are connected
to. If you do that by mistake, you can turn the HDHRs on, then use
the NetworkManager GUI to enable those Ethernet ports. Then you will
need to restart the ISD DHCP server:

sudo systemctl restart isc-dhcp-server

That is needed as the ISC DHCP server only looks for the IP addresses
matching its subnet{} configurations when it is first started.
_______________________________________________
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

On Sat, Dec 7, 2019 at 11:17 PM Stephen Worthington <
stephen_agent@jsw.gen.nz> wrote:

> On Sat, 7 Dec 2019 14:28:42 -0500, you wrote:
>
> >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.
>
> So that makes it unlikely that it was a traffic problem that caused
> the bad recordings.
>
> When you say "failed", what exactly happened? Did the recordings just
> stop, or did they complete but had lots of errors?
>

Yes, the size of the files stopped growing and the "tuner in use" lights
went out.

>
> >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?
>
> I am presuming that you have your MythTV box and HDHRs all connected
> to the same "smart switch" and on the same subnet. If so, then the
> packets between the HDHRs and the MythTV box will never be going to
> the router, and will not be affected by its QoS operations. The
> packets will be switched by the Ethernet switch between its ports
> without ever getting to the router.
>

Because this is indeed my setup, using the NIC would not make things any
better, or would it?

>
> Ideally, you would want your switch to do DSCP QoS, but it is unlikely
> it is capable of that. QoS in switches is usually only found in
> enterprise grade switches or top end consumer ones. But you certainly
> should look up your switch to see if it is capable of doing DSCP QoS.
>
> I have an EdgeSwitch ES-24-LITE:
>
> https://www.ui.com/edgemax/edgeswitch-lite/
>
> which is an enterprise grade switch and has full QoS capabilities.
> That is one of the features I bought it for. I have it configured to
> do DSCP priority on all ports, but I have never actually tested to see
> if it is working as I do not have any problems that would actually
> need DSCP to be working.
>

At a $20 price point, mine is much less capable than yours.

> _______________________________________________
> 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
>

On Sun, Dec 8, 2019 at 4:39 AM Stephen Worthington <stephen_agent@jsw.gen.nz>
wrote:

> On Sun, 8 Dec 2019 08:46:20 +0100, you wrote:
>
> >On 08/12/2019 07:40, Stephen Worthington wrote:
> >> As for CS3 versus CS5, there are two different ways an HDHR gets used.
> >> One is where it is being recorded, and the other is where it is being
> >> watched directly by a human. For a recording, it would actually be
> >> better to use a TCP connection with error correction and
> >> retransmission, so you could under most circumstances ensure that
> >> there were zero lost or damaged packets. It does not matter to a
> >> recording device if the packets arrive a little late and with variable
> >> timing. So if a TCP connection is used, in theory it would not be
> >> necessary to use a DSCP priority tag at all. Where a human is
> >> watching though, the error correction involved in a TCP connection is
> >> usually unacceptable as it causes "buffering" moments where the
> >> playback stops. So for a human, a high priority for the traffic is
> >> necessary to allow the packets to not be dropped and to travel with
> >> low jitter. So that might well justify using CS5 instead of the CS3
> >> recommended by RFC4594. For recording using UDP packets, CS3 should
> >> be all that is necessary.
> >
> >Stephen, I am wondering about circumstances under which packet drops
> >would occur in a home network at all. Furthermore I am wondering whether
> >you'd have an intelligent device in a home network making decisions
> >about which packets to drop, or whether any such packet dropping would
> >be done by consumer-class boxes that lack the smarts to look at packet
> >classification.
> >
> >The topic you describe is relevant in an enterprise network, but in a
> >home network?
> >
> >The only in-home scenario I can think of is WiFi APs, given that WMM has
> >been a mandatory feature of the standards for some time now. Still, it
> >seems that the mapping of DSCP values to WMM access categories is
> >inconsistent across WiFi vendor implementations, so not very useful in
> >practice.
>
> There did not used to be any common situations where a 1 gigabit
> Ethernet connection in a home network could be flooded and cause
> packet drops. But that changed when hard drives became available that
> could read and write faster than 1 gigabit/s, and it got worse when
> SSDs came along as they are all much faster than that. So now a
> simple file copy across a network connection can use up the entire 1
> gigabit/s easily. That does not cause problems with TCP traffic - a
> packet drop with TCP simply causes a resend and usually will also slow
> down the TCP traffic, preventing further packet drops for a while. But
> with UDP you can get packet drops that cause problems, especially with
> multimedia streams. And it is dead easy for someone (or the system)
> to start heavy traffic like that at any time.
>

I'm using a SSD for my OS and three HDDs for recordings.

>
> For quite a while now, Linux systems have by default set up traffic
> control on the transmit side of Ethernet ports. If you do a command
> like this:
>
> root@mypvr:~# ip link show eth0
> 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel
> master br0 state UP mode DEFAULT group default qlen 1000
> link/ether c8:60:00:15:81:76 brd ff:ff:ff:ff:ff:ff
>
> you will see "qdisc fq_codel" which tells you that the "Queuing
> Discipline" is set to "Fair Queuing with Controlled Delay". The "qlen
> 1000" is the size of the transmit queue. So packets being sent via
> eth0 will be queued and then sent in the order decided by the fq_codel
> algorithm, or dropped as necessary. The command "tc" (Traffic
> Control) allows you to set up all the parameters for this, but the
> default setup is usually all that is needed for a home network.
>
> A command like this:
>
> root@mypvr:~# tc -s qdisc show dev eth0
> qdisc fq_codel 0: root refcnt 2 limit 10240p flows 1024 quantum 1514
> target 5.0ms interval 100.0ms memory_limit 32Mb ecn
> Sent 15430762721 bytes 14388768 pkt (dropped 0, overlimits 0 requeues
> 14)
> backlog 0b 0p requeues 14
> maxpacket 65102 drop_overlimit 0 new_flow_count 11282 ecn_mark 0
> new_flows_len 0 old_flows_len 0
>
> can show you what the traffic control has been doing. I have no idea
> what "requeues 14" means, but "dropped 0" looks good to me.
>
> The problem with network tuners unfortunately is on the receive side
> for a MythTV box - where the MythTV box does not have any control. All
> the receiving Ethernet port can do is receive the packets sent to it.
> Packet dropping happens at the transmit end, or in between. In the
> case of network tuners connected via an Ethernet switch, it will
> normally be the switch that has to drop excess packets, as the
> connection from the tuner to the switch is full speed without any
> contention from other traffic, there being only one device on the
> switch's Ethernet port. And home user type switches rarely have any
> control on how contention is handled, although they may use a sensible
> algorithm. It just depends on how they are designed and what their
> silicon is capable of. You would hope that by now the silicon would
> be able to check the DSCP bits and drop lower priority packets when Tx
> port queue on the switch overflows, but I have never seen any
> datasheet or manual for a home type switch that told you anything
> about that. On cheap switches, it may simply work by FIFO and any
> packet that gets queued for transmission on a switch port when that
> queue is full will simply be dropped.
> _______________________________________________
> 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
>

On Mon, 9 Dec 2019 06:27:31 -0500, you wrote:

>On Sat, Dec 7, 2019 at 11:17 PM Stephen Worthington <
>stephen_agent@jsw.gen.nz> wrote:
>
>> On Sat, 7 Dec 2019 14:28:42 -0500, you wrote:
>>
>> >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.
>>
>> So that makes it unlikely that it was a traffic problem that caused
>> the bad recordings.
>>
>> When you say "failed", what exactly happened? Did the recordings just
>> stop, or did they complete but had lots of errors?
>>
>
>Yes, the size of the files stopped growing and the "tuner in use" lights
>went out.
>
>>
>> >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?
>>
>> I am presuming that you have your MythTV box and HDHRs all connected
>> to the same "smart switch" and on the same subnet. If so, then the
>> packets between the HDHRs and the MythTV box will never be going to
>> the router, and will not be affected by its QoS operations. The
>> packets will be switched by the Ethernet switch between its ports
>> without ever getting to the router.
>>
>
>Because this is indeed my setup, using the NIC would not make things any
>better, or would it?

If the problem is dropped packets due to traffic overload, then the
NIC would help. Or a switch that does DSCP QoS. But a dual Ethernet
card is rather cheaper. The idea is to ensure that the traffic from
the HDHRs gets through unhindered to the backend box.

The problem is that we have no specific evidence that points to there
being a dropped packet problem. Having the recording stop completely
rather than continue but be damaged tends to point to something other
than a packet drop problem. Unless mythbackend can detect the dropped
packets and decides to stop recording, which I think is unlikely. So
we really need to know why mythbackend decided to stop recording. Was
there anything in mythbackend.log that could give any hints? It would
be a good idea to run mythbackend with the "-v record" option to see
if the extra logging will tell us what is going on.

>>
>> Ideally, you would want your switch to do DSCP QoS, but it is unlikely
>> it is capable of that. QoS in switches is usually only found in
>> enterprise grade switches or top end consumer ones. But you certainly
>> should look up your switch to see if it is capable of doing DSCP QoS.
>>
>> I have an EdgeSwitch ES-24-LITE:
>>
>> https://www.ui.com/edgemax/edgeswitch-lite/
>>
>> which is an enterprise grade switch and has full QoS capabilities.
>> That is one of the features I bought it for. I have it configured to
>> do DSCP priority on all ports, but I have never actually tested to see
>> if it is working as I do not have any problems that would actually
>> need DSCP to be working.
>>
>
>At a $20 price point, mine is much less capable than yours.

Indeed, no $20 switch is going to have anything except the most basic
capabilities. Which is unfortunate as more and more multimedia is
delivered via the Internet into home networks that are getting busier
and busier. But most of the people who are setting up a home network
have no idea that there comes a point where a cheap switch is unable
to do what they need. Then the company they are getting their
multimedia from gets the blame.
_______________________________________________
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

Perhaps I am not following closely enough. But are we not talking about the
recording stopping? If so, I pointed out a known problem with Linux that
causes the Linux box to drop connection with a HDHR box. I posted a test to
verify if this is the problem. Has that been tried? I also posted the
solution. I had this exact problem, or at least similar. Has that solution
been ruled out? I seem to have missed that. I also have a similar setup
with not one but two HDHRs and even when recording three shows at once and
perhaps four, my $20 switch has no problem. What am I missing? Just to be
clear on the network setup the small 5 port switch has just three inputs
and one output which goes to the router. There should not be enough traffic
from the two HDHRs to ever overload the 100Mb switch. It is a switch and
should not be dealing with anything from other parts of the network.

On Mon, Dec 9, 2019, 9:53 AM Allen Edwards <allen.p.edwards@gmail.com>
wrote:

> Perhaps I am not following closely enough. But are we not talking about
> the recording stopping? If so, I pointed out a known problem with Linux
> that causes the Linux box to drop connection with a HDHR box. I posted a
> test to verify if this is the problem. Has that been tried? I also posted
> the solution. I had this exact problem, or at least similar. Has that
> solution been ruled out? I seem to have missed that. I also have a similar
> setup with not one but two HDHRs and even when recording three shows at
> once and perhaps four, my $20 switch has no problem. What am I missing?
> Just to be clear on the network setup the small 5 port switch has just
> three inputs and one output which goes to the router. There should not be
> enough traffic from the two HDHRs to ever overload the 100Mb switch. It is
> a switch and should not be dealing with anything from other parts of the
> network.
> ________________________________
>

Allen, are you referring to the ifup/ifdown post from very early in the
thread? Assuming yes how is this implemented? Do I just nano the new file?

>

You will have to edit some of the IP addresses to reflect your situation
but yes, just edit the file on your system. I am not home now so can't
check details so ask if you have any questions and I will reply when I
return.

On Mon, Dec 9, 2019, 10:55 AM Daryl McDonald <darylangela@gmail.com> wrote:

>
>
> On Mon, Dec 9, 2019, 9:53 AM Allen Edwards <allen.p.edwards@gmail.com>
> wrote:
>
>> Perhaps I am not following closely enough. But are we not talking about
>> the recording stopping? If so, I pointed out a known problem with Linux
>> that causes the Linux box to drop connection with a HDHR box. I posted a
>> test to verify if this is the problem. Has that been tried? I also posted
>> the solution. I had this exact problem, or at least similar. Has that
>> solution been ruled out? I seem to have missed that. I also have a similar
>> setup with not one but two HDHRs and even when recording three shows at
>> once and perhaps four, my $20 switch has no problem. What am I missing?
>> Just to be clear on the network setup the small 5 port switch has just
>> three inputs and one output which goes to the router. There should not be
>> enough traffic from the two HDHRs to ever overload the 100Mb switch. It is
>> a switch and should not be dealing with anything from other parts of the
>> network.
>> ________________________________
>>
>
> Allen, are you referring to the ifup/ifdown post from very early in the
> thread? Assuming yes how is this implemented? Do I just nano the new file?
>
>> _______________________________________________
> 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
>

On Mon, Dec 9, 2019 at 3:19 PM Allen Edwards <allen.p.edwards@gmail.com>
wrote:

> You will have to edit some of the IP addresses to reflect your situation
> but yes, just edit the file on your system. I am not home now so can't
> check details so ask if you have any questions and I will reply when I
> return.
>
> On Mon, Dec 9, 2019, 10:55 AM Daryl McDonald <darylangela@gmail.com>
> wrote:
>
>>
>>
>> On Mon, Dec 9, 2019, 9:53 AM Allen Edwards <allen.p.edwards@gmail.com>
>> wrote:
>>
>>> Perhaps I am not following closely enough. But are we not talking about
>>> the recording stopping? If so, I pointed out a known problem with Linux
>>> that causes the Linux box to drop connection with a HDHR box. I posted a
>>> test to verify if this is the problem. Has that been tried? I also posted
>>> the solution. I had this exact problem, or at least similar. Has that
>>> solution been ruled out? I seem to have missed that. I also have a similar
>>> setup with not one but two HDHRs and even when recording three shows at
>>> once and perhaps four, my $20 switch has no problem. What am I missing?
>>> Just to be clear on the network setup the small 5 port switch has just
>>> three inputs and one output which goes to the router. There should not be
>>> enough traffic from the two HDHRs to ever overload the 100Mb switch. It is
>>> a switch and should not be dealing with anything from other parts of the
>>> network.
>>> ________________________________
>>>
>>
>> Allen, are you referring to the ifup/ifdown post from very early in the
>> thread? Assuming yes how is this implemented? Do I just nano the new file?
>>
>>> _____________________________________________
>>
>
I've been waiting to see a failed recording, and paste a "shortlog" here,
but that hasn't happened. Granted recording volume is down due to reruns,
and the only other varriable is that I used the HDHRs to rescan my
channels. Previoulsy, I was using a scan from one of my PCI cards. Could
the scan make a difference? It was the only thing in the howto that I
hadn't done, and it did update one channel relocate. (not related to any
previous failure)
Allen, if I read you correctly, our setups might be slightly different in
that I have four cables in my switch, router, two HDHRs and PC, which,
IIUC, removes IP reservations and routing from the equasion, anyway, for
now, merrily rolling along. (ho ho ho) Daryl

On Thu, Dec 12, 2019 at 6:48 AM Daryl McDonald <darylangela@gmail.com>
wrote:

>
>
> On Mon, Dec 9, 2019 at 3:19 PM Allen Edwards <allen.p.edwards@gmail.com>
> wrote:
>
>> You will have to edit some of the IP addresses to reflect your situation
>> but yes, just edit the file on your system. I am not home now so can't
>> check details so ask if you have any questions and I will reply when I
>> return.
>>
>> On Mon, Dec 9, 2019, 10:55 AM Daryl McDonald <darylangela@gmail.com>
>> wrote:
>>
>>>
>>>
>>> On Mon, Dec 9, 2019, 9:53 AM Allen Edwards <allen.p.edwards@gmail.com>
>>> wrote:
>>>
>>>> Perhaps I am not following closely enough. But are we not talking about
>>>> the recording stopping? If so, I pointed out a known problem with Linux
>>>> that causes the Linux box to drop connection with a HDHR box. I posted a
>>>> test to verify if this is the problem. Has that been tried? I also posted
>>>> the solution. I had this exact problem, or at least similar. Has that
>>>> solution been ruled out? I seem to have missed that. I also have a similar
>>>> setup with not one but two HDHRs and even when recording three shows at
>>>> once and perhaps four, my $20 switch has no problem. What am I missing?
>>>> Just to be clear on the network setup the small 5 port switch has just
>>>> three inputs and one output which goes to the router. There should not be
>>>> enough traffic from the two HDHRs to ever overload the 100Mb switch. It is
>>>> a switch and should not be dealing with anything from other parts of the
>>>> network.
>>>> ________________________________
>>>>
>>>
>>> Allen, are you referring to the ifup/ifdown post from very early in the
>>> thread? Assuming yes how is this implemented? Do I just nano the new file?
>>>
>>>> _____________________________________________
>>>
>>
> I've been waiting to see a failed recording, and paste a "shortlog" here,
> but that hasn't happened. Granted recording volume is down due to reruns,
> and the only other varriable is that I used the HDHRs to rescan my
> channels. Previoulsy, I was using a scan from one of my PCI cards. Could
> the scan make a difference? It was the only thing in the howto that I
> hadn't done, and it did update one channel relocate. (not related to any
> previous failure)
> Allen, if I read you correctly, our setups might be slightly different in
> that I have four cables in my switch, router, two HDHRs and PC, which,
> IIUC, removes IP reservations and routing from the equasion, anyway, for
> now, merrily rolling along. (ho ho ho) Daryl
>

I spoke too soon, two recordings from lastnight between 10 and 11 are only
about half expected size, and appear with an orange border in Steppes:
http://paste.ubuntu.com/p/6NqmrQhMNP/

TIA Daryl

On Thu, Dec 12, 2019 at 4:15 AM Daryl McDonald <darylangela@gmail.com>
wrote:

>
>
> On Thu, Dec 12, 2019 at 6:48 AM Daryl McDonald <darylangela@gmail.com>
> wrote:
>
>>
>>
>> On Mon, Dec 9, 2019 at 3:19 PM Allen Edwards <allen.p.edwards@gmail.com>
>> wrote:
>>
>>> You will have to edit some of the IP addresses to reflect your situation
>>> but yes, just edit the file on your system. I am not home now so can't
>>> check details so ask if you have any questions and I will reply when I
>>> return.
>>>
>>> On Mon, Dec 9, 2019, 10:55 AM Daryl McDonald <darylangela@gmail.com>
>>> wrote:
>>>
>>>>
>>>>
>>>> On Mon, Dec 9, 2019, 9:53 AM Allen Edwards <allen.p.edwards@gmail.com>
>>>> wrote:
>>>>
>>>>> Perhaps I am not following closely enough. But are we not talking
>>>>> about the recording stopping? If so, I pointed out a known problem with
>>>>> Linux that causes the Linux box to drop connection with a HDHR box. I
>>>>> posted a test to verify if this is the problem. Has that been tried? I
>>>>> also posted the solution. I had this exact problem, or at least similar.
>>>>> Has that solution been ruled out? I seem to have missed that. I also have a
>>>>> similar setup with not one but two HDHRs and even when recording three
>>>>> shows at once and perhaps four, my $20 switch has no problem. What am I
>>>>> missing? Just to be clear on the network setup the small 5 port switch has
>>>>> just three inputs and one output which goes to the router. There should not
>>>>> be enough traffic from the two HDHRs to ever overload the 100Mb switch. It
>>>>> is a switch and should not be dealing with anything from other parts of the
>>>>> network.
>>>>> ________________________________
>>>>>
>>>>
>>>> Allen, are you referring to the ifup/ifdown post from very early in the
>>>> thread? Assuming yes how is this implemented? Do I just nano the new file?
>>>>
>>>>> _____________________________________________
>>>>
>>>
>> I've been waiting to see a failed recording, and paste a "shortlog" here,
>> but that hasn't happened. Granted recording volume is down due to reruns,
>> and the only other varriable is that I used the HDHRs to rescan my
>> channels. Previoulsy, I was using a scan from one of my PCI cards. Could
>> the scan make a difference? It was the only thing in the howto that I
>> hadn't done, and it did update one channel relocate. (not related to any
>> previous failure)
>> Allen, if I read you correctly, our setups might be slightly different in
>> that I have four cables in my switch, router, two HDHRs and PC, which,
>> IIUC, removes IP reservations and routing from the equasion, anyway, for
>> now, merrily rolling along. (ho ho ho) Daryl
>>
>
> I spoke too soon, two recordings from lastnight between 10 and 11 are only
> about half expected size, and appear with an orange border in Steppes:
> http://paste.ubuntu.com/p/6NqmrQhMNP/
>
> TIA Daryl
> _______________________________________________
>
>
I also have four cables to my switch. I called three inputs and one an
output but all four are both inputs and outputs so my wording was
confusing. To be clear, there are four ethernet cables plugged into the
switch.

Now that you have a failure, see if another computer can see the HDHRs.

Allen

On Thu, Dec 12, 2019 at 9:43 AM Allen Edwards <allen.p.edwards@gmail.com>
wrote:

>
>
> On Thu, Dec 12, 2019 at 4:15 AM Daryl McDonald <darylangela@gmail.com>
> wrote:
>
>>
>>
>> On Thu, Dec 12, 2019 at 6:48 AM Daryl McDonald <darylangela@gmail.com>
>> wrote:
>>
>>>
>>>
>>> On Mon, Dec 9, 2019 at 3:19 PM Allen Edwards <allen.p.edwards@gmail.com>
>>> wrote:
>>>
>>>> You will have to edit some of the IP addresses to reflect your
>>>> situation but yes, just edit the file on your system. I am not home now so
>>>> can't check details so ask if you have any questions and I will reply when
>>>> I return.
>>>>
>>>> On Mon, Dec 9, 2019, 10:55 AM Daryl McDonald <darylangela@gmail.com>
>>>> wrote:
>>>>
>>>>>
>>>>>
>>>>> On Mon, Dec 9, 2019, 9:53 AM Allen Edwards <allen.p.edwards@gmail.com>
>>>>> wrote:
>>>>>
>>>>>> Perhaps I am not following closely enough. But are we not talking
>>>>>> about the recording stopping? If so, I pointed out a known problem with
>>>>>> Linux that causes the Linux box to drop connection with a HDHR box. I
>>>>>> posted a test to verify if this is the problem. Has that been tried? I
>>>>>> also posted the solution. I had this exact problem, or at least similar.
>>>>>> Has that solution been ruled out? I seem to have missed that. I also have a
>>>>>> similar setup with not one but two HDHRs and even when recording three
>>>>>> shows at once and perhaps four, my $20 switch has no problem. What am I
>>>>>> missing? Just to be clear on the network setup the small 5 port switch has
>>>>>> just three inputs and one output which goes to the router. There should not
>>>>>> be enough traffic from the two HDHRs to ever overload the 100Mb switch. It
>>>>>> is a switch and should not be dealing with anything from other parts of the
>>>>>> network.
>>>>>> ________________________________
>>>>>>
>>>>>
>>>>> Allen, are you referring to the ifup/ifdown post from very early in
>>>>> the thread? Assuming yes how is this implemented? Do I just nano the new
>>>>> file?
>>>>>
>>>>>> _____________________________________________
>>>>>
>>>>
>>> I've been waiting to see a failed recording, and paste a "shortlog"
>>> here, but that hasn't happened. Granted recording volume is down due to
>>> reruns, and the only other varriable is that I used the HDHRs to rescan my
>>> channels. Previoulsy, I was using a scan from one of my PCI cards. Could
>>> the scan make a difference? It was the only thing in the howto that I
>>> hadn't done, and it did update one channel relocate. (not related to any
>>> previous failure)
>>> Allen, if I read you correctly, our setups might be slightly different
>>> in that I have four cables in my switch, router, two HDHRs and PC, which,
>>> IIUC, removes IP reservations and routing from the equasion, anyway, for
>>> now, merrily rolling along. (ho ho ho) Daryl
>>>
>>
>> I spoke too soon, two recordings from lastnight between 10 and 11 are
>> only about half expected size, and appear with an orange border in Steppes:
>> http://paste.ubuntu.com/p/6NqmrQhMNP/
>>
>> TIA Daryl
>> _______________________________________________
>>
>>
> I also have four cables to my switch. I called three inputs and one an
> output but all four are both inputs and outputs so my wording was
> confusing. To be clear, there are four ethernet cables plugged into the
> switch.
>
> Now that you have a failure, see if another computer can see the HDHRs.
>
> Allen
> ___________________________________
>

I can communicate with the HDHRs with a wifi Pi as well as with the
combined FE/BE, but after noticing the failure this morning, I couldn't
generate a backend log until I restarted the backend, so this may be a
flawed test.
Can anyone tell me if the pastebin log indicates what the problem is?

On 12/12/19 10:01 AM, Daryl McDonald wrote:
> Can anyone tell me if the pastebin log indicates what the problem is?

http://paste.ubuntu.com/p/6NqmrQhMNP/ isn't at pastebin.com and only shows
114 lines, possibly more if downloaded, but that requires a
valid OpenID transaction. There were/are 478 lines in the log.

--
Bill
_______________________________________________
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

On Thu, Dec 12, 2019 at 8:02 AM Daryl McDonald <darylangela@gmail.com>
wrote:

>
>
> On Thu, Dec 12, 2019 at 9:43 AM Allen Edwards <allen.p.edwards@gmail.com>
> wrote:
>
>>
>>
>> On Thu, Dec 12, 2019 at 4:15 AM Daryl McDonald <darylangela@gmail.com>
>> wrote:
>>
>>>
>>>
>>> On Thu, Dec 12, 2019 at 6:48 AM Daryl McDonald <darylangela@gmail.com>
>>> wrote:
>>>
>>>>
>>>>
>>>> On Mon, Dec 9, 2019 at 3:19 PM Allen Edwards <allen.p.edwards@gmail.com>
>>>> wrote:
>>>>
>>>>> You will have to edit some of the IP addresses to reflect your
>>>>> situation but yes, just edit the file on your system. I am not home now so
>>>>> can't check details so ask if you have any questions and I will reply when
>>>>> I return.
>>>>>
>>>>> On Mon, Dec 9, 2019, 10:55 AM Daryl McDonald <darylangela@gmail.com>
>>>>> wrote:
>>>>>
>>>>>>
>>>>>>
>>>>>> On Mon, Dec 9, 2019, 9:53 AM Allen Edwards <allen.p.edwards@gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>>> Perhaps I am not following closely enough. But are we not talking
>>>>>>> about the recording stopping? If so, I pointed out a known problem with
>>>>>>> Linux that causes the Linux box to drop connection with a HDHR box. I
>>>>>>> posted a test to verify if this is the problem. Has that been tried? I
>>>>>>> also posted the solution. I had this exact problem, or at least similar.
>>>>>>> Has that solution been ruled out? I seem to have missed that. I also have a
>>>>>>> similar setup with not one but two HDHRs and even when recording three
>>>>>>> shows at once and perhaps four, my $20 switch has no problem. What am I
>>>>>>> missing? Just to be clear on the network setup the small 5 port switch has
>>>>>>> just three inputs and one output which goes to the router. There should not
>>>>>>> be enough traffic from the two HDHRs to ever overload the 100Mb switch. It
>>>>>>> is a switch and should not be dealing with anything from other parts of the
>>>>>>> network.
>>>>>>> ________________________________
>>>>>>>
>>>>>>
>>>>>> Allen, are you referring to the ifup/ifdown post from very early in
>>>>>> the thread? Assuming yes how is this implemented? Do I just nano the new
>>>>>> file?
>>>>>>
>>>>>>> _____________________________________________
>>>>>>
>>>>>
>>>> I've been waiting to see a failed recording, and paste a "shortlog"
>>>> here, but that hasn't happened. Granted recording volume is down due to
>>>> reruns, and the only other varriable is that I used the HDHRs to rescan my
>>>> channels. Previoulsy, I was using a scan from one of my PCI cards. Could
>>>> the scan make a difference? It was the only thing in the howto that I
>>>> hadn't done, and it did update one channel relocate. (not related to any
>>>> previous failure)
>>>> Allen, if I read you correctly, our setups might be slightly different
>>>> in that I have four cables in my switch, router, two HDHRs and PC, which,
>>>> IIUC, removes IP reservations and routing from the equasion, anyway, for
>>>> now, merrily rolling along. (ho ho ho) Daryl
>>>>
>>>
>>> I spoke too soon, two recordings from lastnight between 10 and 11 are
>>> only about half expected size, and appear with an orange border in Steppes:
>>> http://paste.ubuntu.com/p/6NqmrQhMNP/
>>>
>>> TIA Daryl
>>> _______________________________________________
>>>
>>>
>> I also have four cables to my switch. I called three inputs and one an
>> output but all four are both inputs and outputs so my wording was
>> confusing. To be clear, there are four ethernet cables plugged into the
>> switch.
>>
>> Now that you have a failure, see if another computer can see the HDHRs.
>>
>> Allen
>> ___________________________________
>>
>
> I can communicate with the HDHRs with a wifi Pi as well as with the
> combined FE/BE, but after noticing the failure this morning, I couldn't
> generate a backend log until I restarted the backend, so this may be a
> flawed test.
> Can anyone tell me if the pastebin log indicates what the problem is?
> _______________________________________________
>
> If you can communicate with the HDHRs with your Pi but not with your Linux
Myth box then you are having the same problem I had. You should try the fix
I posted, properly edited of course. Note that once you reboot the Myth box
it is too late to do the test with the Pi. What you want to know is if the
HDHRs are online but the Myth box cannot see them at the same time that the
Pi can.

Allen

This one has a few more lines:
http://paste.ubuntu.com/p/Bf6VXYbGnH/

On Thu, Dec 12, 2019 at 11:12 AM Bill Meek <keemllib@gmail.com> wrote:

> On 12/12/19 10:01 AM, Daryl McDonald wrote:
> > Can anyone tell me if the pastebin log indicates what the problem is?
>
> http://paste.ubuntu.com/p/6NqmrQhMNP/ isn't at pastebin.com and only shows
> 114 lines, possibly more if downloaded, but that requires a
> valid OpenID transaction. There were/are 478 lines in the log.
>
> --
> Bill
> _______________________________________________
> 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
>

On 12/12/19 10:17 AM, Daryl McDonald wrote:
> On Thu, Dec 12, 2019 at 11:12 AM Bill Meek <keemllib@gmail.com> wrote:
>
>> On 12/12/19 10:01 AM, Daryl McDonald wrote:
>>> Can anyone tell me if the pastebin log indicates what the problem is?
>>
>> http://paste.ubuntu.com/p/6NqmrQhMNP/ isn't at pastebin.com and only shows
>> 114 lines, possibly more if downloaded, but that requires a
>> valid OpenID transaction. There were/are 478 lines in the log.
>>

> This one has a few more lines:
> http://paste.ubuntu.com/p/Bf6VXYbGnH/

But that's today's log and doesn't include any recording logs. Some
missing files that should have their metadata deleted. And I don't
know if the warnings about cardinput.schedorder = 0 are because
you want a tuner to be offline.

--
Bill
_______________________________________________
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

On Thu, Dec 12, 2019, 12:49 PM Bill Meek <keemllib@gmail.com> wrote:

> On 12/12/19 10:17 AM, Daryl McDonald wrote:
> > On Thu, Dec 12, 2019 at 11:12 AM Bill Meek <keemllib@gmail.com> wrote:
> >
> >> On 12/12/19 10:01 AM, Daryl McDonald wrote:
> >>> Can anyone tell me if the pastebin log indicates what the problem is?
> >>
> >> http://paste.ubuntu.com/p/6NqmrQhMNP/ isn't at pastebin.com and only
> shows
> >> 114 lines, possibly more if downloaded, but that requires a
> >> valid OpenID transaction. There were/are 478 lines in the log.
> >>
>
> > This one has a few more lines:
> > http://paste.ubuntu.com/p/Bf6VXYbGnH/
>
> But that's today's log and doesn't include any recording logs. Some
> missing files that should have their metadata deleted. And I don't
> know if the warnings about cardinput.schedorder = 0 are because
> you want a tuner to be offline.
>
> --
> Bill
> ________________________
>
Sorry, 0's are on purpose, to test HDHRs. Do I have to touch the metadata
file to let it delete?

>

On Thu, Dec 12, 2019 at 12:52 PM Daryl McDonald <darylangela@gmail.com>
wrote:

>
>
> On Thu, Dec 12, 2019, 12:49 PM Bill Meek <keemllib@gmail.com> wrote:
>
>> On 12/12/19 10:17 AM, Daryl McDonald wrote:
>> > On Thu, Dec 12, 2019 at 11:12 AM Bill Meek <keemllib@gmail.com> wrote:
>> >
>> >> On 12/12/19 10:01 AM, Daryl McDonald wrote:
>> >>> Can anyone tell me if the pastebin log indicates what the problem is?
>> >>
>> >> http://paste.ubuntu.com/p/6NqmrQhMNP/ isn't at pastebin.com and only
>> shows
>> >> 114 lines, possibly more if downloaded, but that requires a
>> >> valid OpenID transaction. There were/are 478 lines in the log.
>> >>
>>
>> > This one has a few more lines:
>> > http://paste.ubuntu.com/p/Bf6VXYbGnH/
>>
>> But that's today's log and doesn't include any recording logs. Some
>> missing files that should have their metadata deleted. And I don't
>> know if the warnings about cardinput.schedorder = 0 are because
>> you want a tuner to be offline.
>>
>> --
>> Bill
>> ________________________
>>
> Sorry, 0's are on purpose, to test HDHRs. Do I have to touch the metadata
> file to let it delete?
>

Another test another failure, four recordings fail before 1pm, see paste:
http://paste.ubuntu.com/p/qmwkcSPDGP/

On Thu, Dec 12, 2019, 10:10 AM Daryl McDonald <darylangela@gmail.com> wrote:

>
>
> On Thu, Dec 12, 2019 at 12:52 PM Daryl McDonald <darylangela@gmail.com>
> wrote:
>
>>
>>
>> On Thu, Dec 12, 2019, 12:49 PM Bill Meek <keemllib@gmail.com> wrote:
>>
>>> On 12/12/19 10:17 AM, Daryl McDonald wrote:
>>> > On Thu, Dec 12, 2019 at 11:12 AM Bill Meek <keemllib@gmail.com> wrote:
>>> >
>>> >> On 12/12/19 10:01 AM, Daryl McDonald wrote:
>>> >>> Can anyone tell me if the pastebin log indicates what the problem is?
>>> >>
>>> >> http://paste.ubuntu.com/p/6NqmrQhMNP/ isn't at pastebin.com and only
>>> shows
>>> >> 114 lines, possibly more if downloaded, but that requires a
>>> >> valid OpenID transaction. There were/are 478 lines in the log.
>>> >>
>>>
>>> > This one has a few more lines:
>>> > http://paste.ubuntu.com/p/Bf6VXYbGnH/
>>>
>>> But that's today's log and doesn't include any recording logs. Some
>>> missing files that should have their metadata deleted. And I don't
>>> know if the warnings about cardinput.schedorder = 0 are because
>>> you want a tuner to be offline.
>>>
>>> --
>>> Bill
>>> ________________________
>>>
>> Sorry, 0's are on purpose, to test HDHRs. Do I have to touch the metadata
>> file to let it delete?
>>
>
> Another test another failure, four recordings fail before 1pm, see paste:
> http://paste.ubuntu.com/p/qmwkcSPDGP/
> _______________________________________________
> 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


Have you tried the fix I posted?

>
>

On Thu, Dec 12, 2019, 1:17 PM Allen Edwards <allen.p.edwards@gmail.com>
wrote:

>
>
> On Thu, Dec 12, 2019, 10:10 AM Daryl McDonald <darylangela@gmail.com>
> wrote:
>
>>
>>
>> On Thu, Dec 12, 2019 at 12:52 PM Daryl McDonald <darylangela@gmail.com>
>> wrote:
>>
>>>
>>>
>>> On Thu, Dec 12, 2019, 12:49 PM Bill Meek <keemllib@gmail.com> wrote:
>>>
>>>> On 12/12/19 10:17 AM, Daryl McDonald wrote:
>>>> > On Thu, Dec 12, 2019 at 11:12 AM Bill Meek <keemllib@gmail.com>
>>>> wrote:
>>>> >
>>>> >> On 12/12/19 10:01 AM, Daryl McDonald wrote:
>>>> >>> Can anyone tell me if the pastebin log indicates what the problem
>>>> is?
>>>> >>
>>>> >> http://paste.ubuntu.com/p/6NqmrQhMNP/ isn't at pastebin.com and
>>>> only shows
>>>> >> 114 lines, possibly more if downloaded, but that requires a
>>>> >> valid OpenID transaction. There were/are 478 lines in the log.
>>>> >>
>>>>
>>>> > This one has a few more lines:
>>>> > http://paste.ubuntu.com/p/Bf6VXYbGnH/
>>>>
>>>> But that's today's log and doesn't include any recording logs. Some
>>>> missing files that should have their metadata deleted. And I don't
>>>> know if the warnings about cardinput.schedorder = 0 are because
>>>> you want a tuner to be offline.
>>>>
>>>> --
>>>> Bill
>>>> ________________________
>>>>
>>> Sorry, 0's are on purpose, to test HDHRs. Do I have to touch the
>>> metadata file to let it delete?
>>>
>>
>> Another test another failure, four recordings fail before 1pm, see paste:
>> http://paste.ubuntu.com/p/qmwkcSPDGP/
>> _______________________________________________
>> 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
>
>
> Have you tried the fix I posted?
>
>>
>> ________________________________
>
I don't fully understand it. Plus after this fail, I was able to access the
HDHRs from the FE/BE, which you were not able to, correct?

>

On Thu, Dec 12, 2019, 10:23 AM Daryl McDonald <darylangela@gmail.com> wrote:

>
>
> On Thu, Dec 12, 2019, 1:17 PM Allen Edwards <allen.p.edwards@gmail.com>
> wrote:
>
>>
>>
>> On Thu, Dec 12, 2019, 10:10 AM Daryl McDonald <darylangela@gmail.com>
>> wrote:
>>
>>>
>>>
>>> On Thu, Dec 12, 2019 at 12:52 PM Daryl McDonald <darylangela@gmail.com>
>>> wrote:
>>>
>>>>
>>>>
>>>> On Thu, Dec 12, 2019, 12:49 PM Bill Meek <keemllib@gmail.com> wrote:
>>>>
>>>>> On 12/12/19 10:17 AM, Daryl McDonald wrote:
>>>>> > On Thu, Dec 12, 2019 at 11:12 AM Bill Meek <keemllib@gmail.com>
>>>>> wrote:
>>>>> >
>>>>> >> On 12/12/19 10:01 AM, Daryl McDonald wrote:
>>>>> >>> Can anyone tell me if the pastebin log indicates what the problem
>>>>> is?
>>>>> >>
>>>>> >> http://paste.ubuntu.com/p/6NqmrQhMNP/ isn't at pastebin.com and
>>>>> only shows
>>>>> >> 114 lines, possibly more if downloaded, but that requires a
>>>>> >> valid OpenID transaction. There were/are 478 lines in the log.
>>>>> >>
>>>>>
>>>>> > This one has a few more lines:
>>>>> > http://paste.ubuntu.com/p/Bf6VXYbGnH/
>>>>>
>>>>> But that's today's log and doesn't include any recording logs. Some
>>>>> missing files that should have their metadata deleted. And I don't
>>>>> know if the warnings about cardinput.schedorder = 0 are because
>>>>> you want a tuner to be offline.
>>>>>
>>>>> --
>>>>> Bill
>>>>> ________________________
>>>>>
>>>> Sorry, 0's are on purpose, to test HDHRs. Do I have to touch the
>>>> metadata file to let it delete?
>>>>
>>>
>>> Another test another failure, four recordings fail before 1pm, see paste:
>>> http://paste.ubuntu.com/p/qmwkcSPDGP/
>>> _______________________________________________
>>> 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
>>
>>
>> Have you tried the fix I posted?
>>
>>>
>>> ________________________________
>>
> I don't fully understand it. Plus after this fail, I was able to access
> the HDHRs from the FE/BE, which you were not able to, correct?
>
>> _______________________________________________
> 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


My system works perfectly. Before the fix, Linux would occasionally drop
connection with the hdhrs I was always able to contact the hdhrs from a
Windows computer even when the Linux box could not. As far as I can tell
the fix I posted will fix your problems. But you can prove it with the rest
I described several times.

>
>

On Sat, Dec 7, 2019, 11:36 AM Allen Edwards <allen.p.edwards@gmail.com>
wrote:

> I have no idea if this will be helpful but I had several issues getting my
> HDHR tuners to work. I provide these in case they might be useful.
>
> Myth address is 192.168.1.111 and is static. I set it as reserved on the
> router. I also set the HDHR addresses as reserved.
>
> I start the tuners from rc.local. Old school but works.
> Here is the code. I believe this was from the vendors website.
> hdhomerun_config 10137DC1 set /ir/target "192.168.1.111:5000 no_clear"
> If you need to allow more time to go by, you can add a delay before this
> command.
>
This part is outside my capabilities, probably would need more time if I
get the mobo to play nice with ACPI.

>
> I had a power supply issue as well. The module that I bought with the HDHR
> did not put out enough current so I got ones rated for more current.
>
> I also had random failures. The computer would lose contact with the
> turners every few weeks. I traced it to a linux problem as the tuners were
> still visible from a Windows computer on the same network. That
> troubleshooting tip was provided by Silicon Dust.
>
> Here is the solution.
>
> dad@NewMyth:~$ more /etc/network/interfaces
> # interfaces(5) file used by ifup(8) and ifdown(8)
> auto lo
> iface lo inet loopback
> auto enp2s0
> iface enp2s0 inet static
> address 192.168.1.111
> netmask 255.255.255.0
> gateway 192.168.1.1
> broadcast 192.168.1.255
> dns-nameservers 8.8.8.8 8.8.4.4
>
> Hope this helps.
>
> Allen
>

I've set my FE/BE reserved to .210 and the HDHRs to .211, and .212, no
change to gateway and netmask, beyond this I need help.

>
>
> _______________________________________________
> 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
>

On Thu, Dec 12, 2019, 10:29 AM Daryl McDonald <darylangela@gmail.com> wrote:

>
>
> On Sat, Dec 7, 2019, 11:36 AM Allen Edwards <allen.p.edwards@gmail.com>
> wrote:
>
>> I have no idea if this will be helpful but I had several issues getting
>> my HDHR tuners to work. I provide these in case they might be useful.
>>
>> Myth address is 192.168.1.111 and is static. I set it as reserved on the
>> router. I also set the HDHR addresses as reserved.
>>
>> I start the tuners from rc.local. Old school but works.
>> Here is the code. I believe this was from the vendors website.
>> hdhomerun_config 10137DC1 set /ir/target "192.168.1.111:5000 no_clear"
>> If you need to allow more time to go by, you can add a delay before this
>> command.
>>
> This part is outside my capabilities, probably would need more time if I
> get the mobo to play nice with ACPI.
>
>>
>> I had a power supply issue as well. The module that I bought with the
>> HDHR did not put out enough current so I got ones rated for more current.
>>
>> I also had random failures. The computer would lose contact with the
>> turners every few weeks. I traced it to a linux problem as the tuners were
>> still visible from a Windows computer on the same network. That
>> troubleshooting tip was provided by Silicon Dust.
>>
>> Here is the solution.
>>
>> dad@NewMyth:~$ more /etc/network/interfaces
>> # interfaces(5) file used by ifup(8) and ifdown(8)
>> auto lo
>> iface lo inet loopback
>> auto enp2s0
>> iface enp2s0 inet static
>> address 192.168.1.111
>> netmask 255.255.255.0
>> gateway 192.168.1.1
>> broadcast 192.168.1.255
>> dns-nameservers 8.8.8.8 8.8.4.4
>>
>> Hope this helps.
>>
>> Allen
>>
>
> I've set my FE/BE reserved to .210 and the HDHRs to .211, and .212, no
> change to gateway and netmask, beyond this I need help.
>
>>
>>
>> _______________________________________________
>> 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
>>
> _______________________________________________
> 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


What you did is not enough. I did that from day 1 and had the problem.
Perhaps you can ask a specific question based on the fix I posted.

>
>

On 12/12/19 11:52 AM, Daryl McDonald wrote:
> On Thu, Dec 12, 2019, 12:49 PM Bill Meek <keemllib@gmail.com> wrote:
...
>> But that's today's log and doesn't include any recording logs. Some
>> missing files that should have their metadata deleted. And I don't
>> know if the warnings about cardinput.schedorder = 0 are because
>> you want a tuner to be offline.
>>
>> --
>> Bill
>> ________________________
>>
> Sorry, 0's are on purpose, to test HDHRs. Do I have to touch the metadata
> file to let it delete?

https://www.mythtv.org/wiki/Frequently_Asked_Questions#How_do_I_remove_recordings_that_no_longer_exist_on_disk.3F

--
Bill
_______________________________________________
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

On Thu, Dec 12, 2019 at 1:45 PM Allen Edwards <allen.p.edwards@gmail.com>
wrote:

>
>
> On Thu, Dec 12, 2019, 10:29 AM Daryl McDonald <darylangela@gmail.com>
> wrote:
>
>>
>>
>> On Sat, Dec 7, 2019, 11:36 AM Allen Edwards <allen.p.edwards@gmail.com>
>> wrote:
>>
>>> I have no idea if this will be helpful but I had several issues getting
>>> my HDHR tuners to work. I provide these in case they might be useful.
>>>
>>> Myth address is 192.168.1.111 and is static. I set it as reserved on the
>>> router. I also set the HDHR addresses as reserved.
>>>
>>> I start the tuners from rc.local. Old school but works.
>>> Here is the code. I believe this was from the vendors website.
>>> hdhomerun_config 10137DC1 set /ir/target "192.168.1.111:5000 no_clear"
>>> If you need to allow more time to go by, you can add a delay before this
>>> command.
>>>
>> This part is outside my capabilities, probably would need more time if I
>> get the mobo to play nice with ACPI.
>>
>>>
>>> I had a power supply issue as well. The module that I bought with the
>>> HDHR did not put out enough current so I got ones rated for more current.
>>>
>>> I also had random failures. The computer would lose contact with the
>>> turners every few weeks. I traced it to a linux problem as the tuners were
>>> still visible from a Windows computer on the same network. That
>>> troubleshooting tip was provided by Silicon Dust.
>>>
>>> Here is the solution.
>>>
>>> dad@NewMyth:~$ more /etc/network/interfaces
>>> # interfaces(5) file used by ifup(8) and ifdown(8)
>>> auto lo
>>> iface lo inet loopback
>>> auto enp2s0
>>> iface enp2s0 inet static
>>> address 192.168.1.111
>>> netmask 255.255.255.0
>>> gateway 192.168.1.1
>>> broadcast 192.168.1.255
>>> dns-nameservers 8.8.8.8 8.8.4.4
>>>
>>> Hope this helps.
>>>
>>> Allen
>>>
>>
>> I've set my FE/BE reserved to .210 and the HDHRs to .211, and .212, no
>> change to gateway and netmask, beyond this I need help.
>>
>>>
>>>
>>> _______________________________________________
>>> 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
>>>
>> _______________________________________________
>> 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
>
>
> What you did is not enough. I did that from day 1 and had the problem.
> Perhaps you can ask a specific question based on the fix I posted.
>
>>
>> OK Allen I'm all in, this is my interfaces file now:
$ cat /etc/network/interfaces
# interfaces(5) file used by ifup(8) and ifdown(8)
auto lo
iface lo inet loopback
auto enp2s0
iface enp2s0 inet static
address 192.168.0.210
netmask 255.255.255.0
gateway 192.168.0.1
broadcast 192.168.0.255
dns-nameservers 8.8.8.8 8.8.4.4
My only question is, where did you get the dns-nameservers values from? Do
I need to edit these?

On Thu, Dec 12, 2019 at 2:34 PM Bill Meek <keemllib@gmail.com> wrote:

> On 12/12/19 11:52 AM, Daryl McDonald wrote:
> > On Thu, Dec 12, 2019, 12:49 PM Bill Meek <keemllib@gmail.com> wrote:
> ...
> >> But that's today's log and doesn't include any recording logs. Some
> >> missing files that should have their metadata deleted. And I don't
> >> know if the warnings about cardinput.schedorder = 0 are because
> >> you want a tuner to be offline.
> >>
> >> --
> >> Bill
> >> ________________________
> >>
> > Sorry, 0's are on purpose, to test HDHRs. Do I have to touch the metadata
> > file to let it delete?
>
>
> https://www.mythtv.org/wiki/Frequently_Asked_Questions#How_do_I_remove_recordings_that_no_longer_exist_on_disk.3F
>
> --
> Bill
>

Thanks Bill, find orphans, mostly did the trick, except for this last one.
I tried three times and it never gets deleted.:
Please select from the following
1. Delete orphaned video files
2. Delete other files
3. Refresh list
> 1
The following files will be deleted
trieli: /mnt/storage3/mythtv/recordings/1071-201910310200000.ts
0.0B

Total: 0.0B
Are you sure you want to continue?
> yes
Orphaned video files
trieli: /mnt/storage3/mythtv/recordings/1071-201910310200000.ts
0.0B

Total: 0.0B

Daryl

On Thu, Dec 12, 2019 at 1:31 PM Daryl McDonald <darylangela@gmail.com>
wrote:

>
>
> On Thu, Dec 12, 2019 at 1:45 PM Allen Edwards <allen.p.edwards@gmail.com>
> wrote:
>
>>
>>
>> On Thu, Dec 12, 2019, 10:29 AM Daryl McDonald <darylangela@gmail.com>
>> wrote:
>>
>>>
>>>
>>> On Sat, Dec 7, 2019, 11:36 AM Allen Edwards <allen.p.edwards@gmail.com>
>>> wrote:
>>>
>>>> I have no idea if this will be helpful but I had several issues getting
>>>> my HDHR tuners to work. I provide these in case they might be useful.
>>>>
>>>> Myth address is 192.168.1.111 and is static. I set it as reserved on
>>>> the router. I also set the HDHR addresses as reserved.
>>>>
>>>> I start the tuners from rc.local. Old school but works.
>>>> Here is the code. I believe this was from the vendors website.
>>>> hdhomerun_config 10137DC1 set /ir/target "192.168.1.111:5000 no_clear"
>>>> If you need to allow more time to go by, you can add a delay before
>>>> this command.
>>>>
>>> This part is outside my capabilities, probably would need more time if I
>>> get the mobo to play nice with ACPI.
>>>
>>>>
>>>> I had a power supply issue as well. The module that I bought with the
>>>> HDHR did not put out enough current so I got ones rated for more current.
>>>>
>>>> I also had random failures. The computer would lose contact with the
>>>> turners every few weeks. I traced it to a linux problem as the tuners were
>>>> still visible from a Windows computer on the same network. That
>>>> troubleshooting tip was provided by Silicon Dust.
>>>>
>>>> Here is the solution.
>>>>
>>>> dad@NewMyth:~$ more /etc/network/interfaces
>>>> # interfaces(5) file used by ifup(8) and ifdown(8)
>>>> auto lo
>>>> iface lo inet loopback
>>>> auto enp2s0
>>>> iface enp2s0 inet static
>>>> address 192.168.1.111
>>>> netmask 255.255.255.0
>>>> gateway 192.168.1.1
>>>> broadcast 192.168.1.255
>>>> dns-nameservers 8.8.8.8 8.8.4.4
>>>>
>>>> Hope this helps.
>>>>
>>>> Allen
>>>>
>>>
>>> I've set my FE/BE reserved to .210 and the HDHRs to .211, and .212, no
>>> change to gateway and netmask, beyond this I need help.
>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> 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
>>>>
>>> _______________________________________________
>>> 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
>>
>>
>> What you did is not enough. I did that from day 1 and had the problem.
>> Perhaps you can ask a specific question based on the fix I posted.
>>
>>>
>>> OK Allen I'm all in, this is my interfaces file now:
> $ cat /etc/network/interfaces
> # interfaces(5) file used by ifup(8) and ifdown(8)
> auto lo
> iface lo inet loopback
> auto enp2s0
> iface enp2s0 inet static
> address 192.168.0.210
> netmask 255.255.255.0
> gateway 192.168.0.1
> broadcast 192.168.0.255
> dns-nameservers 8.8.8.8 8.8.4.4
> My only question is, where did you get the dns-nameservers values from? Do
> I need to edit these?
> _______________________________________________
>
> The nameserver are Google https://tunecomp.net/google-dns-8-8-8-8/

Maybe I will switch my router to use these as well.

Allen

On Thu, 12 Dec 2019 16:31:02 -0500, you wrote:

>On Thu, Dec 12, 2019 at 1:45 PM Allen Edwards <allen.p.edwards@gmail.com>
>wrote:
>
>>
>>
>> On Thu, Dec 12, 2019, 10:29 AM Daryl McDonald <darylangela@gmail.com>
>> wrote:
>>
>>>
>>>
>>> On Sat, Dec 7, 2019, 11:36 AM Allen Edwards <allen.p.edwards@gmail.com>
>>> wrote:
>>>
>>>> I have no idea if this will be helpful but I had several issues getting
>>>> my HDHR tuners to work. I provide these in case they might be useful.
>>>>
>>>> Myth address is 192.168.1.111 and is static. I set it as reserved on the
>>>> router. I also set the HDHR addresses as reserved.
>>>>
>>>> I start the tuners from rc.local. Old school but works.
>>>> Here is the code. I believe this was from the vendors website.
>>>> hdhomerun_config 10137DC1 set /ir/target "192.168.1.111:5000 no_clear"
>>>> If you need to allow more time to go by, you can add a delay before this
>>>> command.
>>>>
>>> This part is outside my capabilities, probably would need more time if I
>>> get the mobo to play nice with ACPI.
>>>
>>>>
>>>> I had a power supply issue as well. The module that I bought with the
>>>> HDHR did not put out enough current so I got ones rated for more current.
>>>>
>>>> I also had random failures. The computer would lose contact with the
>>>> turners every few weeks. I traced it to a linux problem as the tuners were
>>>> still visible from a Windows computer on the same network. That
>>>> troubleshooting tip was provided by Silicon Dust.
>>>>
>>>> Here is the solution.
>>>>
>>>> dad@NewMyth:~$ more /etc/network/interfaces
>>>> # interfaces(5) file used by ifup(8) and ifdown(8)
>>>> auto lo
>>>> iface lo inet loopback
>>>> auto enp2s0
>>>> iface enp2s0 inet static
>>>> address 192.168.1.111
>>>> netmask 255.255.255.0
>>>> gateway 192.168.1.1
>>>> broadcast 192.168.1.255
>>>> dns-nameservers 8.8.8.8 8.8.4.4
>>>>
>>>> Hope this helps.
>>>>
>>>> Allen
>>>>
>>>
>>> I've set my FE/BE reserved to .210 and the HDHRs to .211, and .212, no
>>> change to gateway and netmask, beyond this I need help.

>>
>> What you did is not enough. I did that from day 1 and had the problem.
>> Perhaps you can ask a specific question based on the fix I posted.
>>
>>>
>>> OK Allen I'm all in, this is my interfaces file now:
> $ cat /etc/network/interfaces
># interfaces(5) file used by ifup(8) and ifdown(8)
>auto lo
>iface lo inet loopback
>auto enp2s0
>iface enp2s0 inet static
> address 192.168.0.210
> netmask 255.255.255.0
> gateway 192.168.0.1
> broadcast 192.168.0.255
> dns-nameservers 8.8.8.8 8.8.4.4
>My only question is, where did you get the dns-nameservers values from? Do
>I need to edit these?

You would normally want to use the nameservers that your router should
be getting from your ISP. Your router may be able to tell you what
they are. Using Google's public nameservers as above should work for
most things, but there can be some subtle problems (and benefits). For
example, if your ISP runs local CDN servers (say Akamai servers), then
anything you would normally have got from the local CDN servers will
now be received from some global server somewhere much further away if
you use Google DNS. And you may be unable to access ISP services that
are provided only to your ISP's customers from this PC.

If you can find the correct ISP nameserver addresses from your router
of maybe from a web page on your ISP's help pages, or by calling their
helpdesk, then you can put them here. ISP nameserver addresses
normally do not change, but it can happen if they have to reorganise
their IP addresses (especially if someone takes them over), and if
that happens, then the static IPs that you put here will need to be
changed also. It is unlikely that your ISP will inform you if they
change the addresses, as your router will normally pick up the new
ones automatically. If you use Google's nameservers, then those
addresses are extremely unlikely to change. And if they ever do, it
will be big news on the Internet. But you are giving Google
information about what DNS addresses you are using.

I think it may be possible to do partial DHCP, where you use a static
IP address as above, but get things like the nameserver addresses
using DHCP. I have never done that using the interfaces file, but it
is probably possible using some scripting. Likely way beyond your
capabilities.

Also, using /etc/network/interfaces on a system that is using
NetworkManager as yours is, there can be lots of complications. I
found I had to disable NetworkManager to get some things to work, and
that may have included the "dns-nameservers" options. It is a very
long time ago that I did this, so my recollection is cloudy. So
overall I would recommend not doing static IP addresses this way
without removing NetworkManager. It gets too complicated.

Instead, I would recommend that you use the NetworkManager GUI to set
a "Manual" IP address. "Manual" is NetworkManager's name for
"Static". You can then set the DNS options on the same screen to
"Automatic" and that will get the DNS server addresses using DHCP, but
have a static IP address. The best of both worlds, unless it was a
NetworkManager bug that was causing Allen's problems.

Click on the NetworkManager icon, usually at the top of the screen,
often on the right somewhere. Mine looks like a little white box with
a line dropping down to two more little white boxes below it. Click
on the cogwheel icon to open the settings for the Ethernet card, then
on the "IPv4" tab. Select "IPv4 Method" "Manual" and fill in the
"Address" field with the static IP address you want. The "Netmask"
field should normally be set to "255.255.255.0" and the "Gateway" to
the IPv4 address of your router. Leave the "DNS" and "Routes" options
set to "Automatic". Click "Apply".
_______________________________________________
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

On Fri, Dec 13, 2019 at 6:14 AM Stephen Worthington <
stephen_agent@jsw.gen.nz> wrote:

> On Thu, 12 Dec 2019 16:31:02 -0500, you wrote:
>
> >On Thu, Dec 12, 2019 at 1:45 PM Allen Edwards <allen.p.edwards@gmail.com>
> >wrote:
> >
> >>
> >>
> >> On Thu, Dec 12, 2019, 10:29 AM Daryl McDonald <darylangela@gmail.com>
> >> wrote:
> >>
> >>>
> >>>
> >>> On Sat, Dec 7, 2019, 11:36 AM Allen Edwards <allen.p.edwards@gmail.com
> >
> >>> wrote:
> >>>
> >>>> I have no idea if this will be helpful but I had several issues
> getting
> >>>> my HDHR tuners to work. I provide these in case they might be useful.
> >>>>
> >>>> Myth address is 192.168.1.111 and is static. I set it as reserved on
> the
> >>>> router. I also set the HDHR addresses as reserved.
> >>>>
> >>>> I start the tuners from rc.local. Old school but works.
> >>>> Here is the code. I believe this was from the vendors website.
> >>>> hdhomerun_config 10137DC1 set /ir/target "192.168.1.111:5000
> no_clear"
> >>>> If you need to allow more time to go by, you can add a delay before
> this
> >>>> command.
> >>>>
> >>> This part is outside my capabilities, probably would need more time if
> I
> >>> get the mobo to play nice with ACPI.
> >>>
> >>>>
> >>>> I had a power supply issue as well. The module that I bought with the
> >>>> HDHR did not put out enough current so I got ones rated for more
> current.
> >>>>
> >>>> I also had random failures. The computer would lose contact with the
> >>>> turners every few weeks. I traced it to a linux problem as the tuners
> were
> >>>> still visible from a Windows computer on the same network. That
> >>>> troubleshooting tip was provided by Silicon Dust.
> >>>>
> >>>> Here is the solution.
> >>>>
> >>>> dad@NewMyth:~$ more /etc/network/interfaces
> >>>> # interfaces(5) file used by ifup(8) and ifdown(8)
> >>>> auto lo
> >>>> iface lo inet loopback
> >>>> auto enp2s0
> >>>> iface enp2s0 inet static
> >>>> address 192.168.1.111
> >>>> netmask 255.255.255.0
> >>>> gateway 192.168.1.1
> >>>> broadcast 192.168.1.255
> >>>> dns-nameservers 8.8.8.8 8.8.4.4
> >>>>
> >>>> Hope this helps.
> >>>>
> >>>> Allen
> >>>>
> >>>
> >>> I've set my FE/BE reserved to .210 and the HDHRs to .211, and .212, no
> >>> change to gateway and netmask, beyond this I need help.
>
> >>
> >> What you did is not enough. I did that from day 1 and had the problem.
> >> Perhaps you can ask a specific question based on the fix I posted.
> >>
> >>>
> >>> OK Allen I'm all in, this is my interfaces file now:
> > $ cat /etc/network/interfaces
> ># interfaces(5) file used by ifup(8) and ifdown(8)
> >auto lo
> >iface lo inet loopback
> >auto enp2s0
> >iface enp2s0 inet static
> > address 192.168.0.210
> > netmask 255.255.255.0
> > gateway 192.168.0.1
> > broadcast 192.168.0.255
> > dns-nameservers 8.8.8.8 8.8.4.4
> >My only question is, where did you get the dns-nameservers values from? Do
> >I need to edit these?
>
> You would normally want to use the nameservers that your router should
> be getting from your ISP. Your router may be able to tell you what
> they are. Using Google's public nameservers as above should work for
> most things, but there can be some subtle problems (and benefits). For
> example, if your ISP runs local CDN servers (say Akamai servers), then
> anything you would normally have got from the local CDN servers will
> now be received from some global server somewhere much further away if
> you use Google DNS. And you may be unable to access ISP services that
> are provided only to your ISP's customers from this PC.
>
> If you can find the correct ISP nameserver addresses from your router
> of maybe from a web page on your ISP's help pages, or by calling their
> helpdesk, then you can put them here. ISP nameserver addresses
> normally do not change, but it can happen if they have to reorganise
> their IP addresses (especially if someone takes them over), and if
> that happens, then the static IPs that you put here will need to be
> changed also. It is unlikely that your ISP will inform you if they
> change the addresses, as your router will normally pick up the new
> ones automatically. If you use Google's nameservers, then those
> addresses are extremely unlikely to change. And if they ever do, it
> will be big news on the Internet. But you are giving Google
> information about what DNS addresses you are using.
>
> I think it may be possible to do partial DHCP, where you use a static
> IP address as above, but get things like the nameserver addresses
> using DHCP. I have never done that using the interfaces file, but it
> is probably possible using some scripting. Likely way beyond your
> capabilities.
>
> Also, using /etc/network/interfaces on a system that is using
> NetworkManager as yours is, there can be lots of complications. I
> found I had to disable NetworkManager to get some things to work, and
> that may have included the "dns-nameservers" options. It is a very
> long time ago that I did this, so my recollection is cloudy. So
> overall I would recommend not doing static IP addresses this way
> without removing NetworkManager. It gets too complicated.
>
> Instead, I would recommend that you use the NetworkManager GUI to set
> a "Manual" IP address. "Manual" is NetworkManager's name for
> "Static". You can then set the DNS options on the same screen to
> "Automatic" and that will get the DNS server addresses using DHCP, but
> have a static IP address. The best of both worlds, unless it was a
> NetworkManager bug that was causing Allen's problems.
>
> Click on the NetworkManager icon, usually at the top of the screen,
> often on the right somewhere. Mine looks like a little white box with
> a line dropping down to two more little white boxes below it. Click
> on the cogwheel icon to open the settings for the Ethernet card, then
> on the "IPv4" tab. Select "IPv4 Method" "Manual" and fill in the
> "Address" field with the static IP address you want. The "Netmask"
> field should normally be set to "255.255.255.0" and the "Gateway" to
> the IPv4 address of your router. Leave the "DNS" and "Routes" options
> set to "Automatic". Click "Apply".
> _________________________________________
>

I understand what you are saying Stephen, but I have a couple questions. If
I go the manual method, would I first have to revert my
"/etc/network/interfaces" file to original state? (I did get successful
News and NFL recordings on HDHR last night) Secondly, I've employed a fix,
recommended by this site "
https://datawookie.netlify.com/blog/2018/10/dns-on-ubuntu-18.04/" to
insure that nameserver settings required for my VPN survive a reboot. I
assume this should be taken into account when using your's or Allen's fix,
right?
I just checked and the change to /etc/network/interfaces (Allen's fix) has
not harmed my VPN usage.

On Fri, 13 Dec 2019 09:51:00 -0500, you wrote:

>On Fri, Dec 13, 2019 at 6:14 AM Stephen Worthington <
>stephen_agent@jsw.gen.nz> wrote:
>
>> On Thu, 12 Dec 2019 16:31:02 -0500, you wrote:
>>
>> >On Thu, Dec 12, 2019 at 1:45 PM Allen Edwards <allen.p.edwards@gmail.com>
>> >wrote:
>> >
>> >>
>> >>
>> >> On Thu, Dec 12, 2019, 10:29 AM Daryl McDonald <darylangela@gmail.com>
>> >> wrote:
>> >>
>> >>>
>> >>>
>> >>> On Sat, Dec 7, 2019, 11:36 AM Allen Edwards <allen.p.edwards@gmail.com
>> >
>> >>> wrote:
>> >>>
>> >>>> I have no idea if this will be helpful but I had several issues
>> getting
>> >>>> my HDHR tuners to work. I provide these in case they might be useful.
>> >>>>
>> >>>> Myth address is 192.168.1.111 and is static. I set it as reserved on
>> the
>> >>>> router. I also set the HDHR addresses as reserved.
>> >>>>
>> >>>> I start the tuners from rc.local. Old school but works.
>> >>>> Here is the code. I believe this was from the vendors website.
>> >>>> hdhomerun_config 10137DC1 set /ir/target "192.168.1.111:5000
>> no_clear"
>> >>>> If you need to allow more time to go by, you can add a delay before
>> this
>> >>>> command.
>> >>>>
>> >>> This part is outside my capabilities, probably would need more time if
>> I
>> >>> get the mobo to play nice with ACPI.
>> >>>
>> >>>>
>> >>>> I had a power supply issue as well. The module that I bought with the
>> >>>> HDHR did not put out enough current so I got ones rated for more
>> current.
>> >>>>
>> >>>> I also had random failures. The computer would lose contact with the
>> >>>> turners every few weeks. I traced it to a linux problem as the tuners
>> were
>> >>>> still visible from a Windows computer on the same network. That
>> >>>> troubleshooting tip was provided by Silicon Dust.
>> >>>>
>> >>>> Here is the solution.
>> >>>>
>> >>>> dad@NewMyth:~$ more /etc/network/interfaces
>> >>>> # interfaces(5) file used by ifup(8) and ifdown(8)
>> >>>> auto lo
>> >>>> iface lo inet loopback
>> >>>> auto enp2s0
>> >>>> iface enp2s0 inet static
>> >>>> address 192.168.1.111
>> >>>> netmask 255.255.255.0
>> >>>> gateway 192.168.1.1
>> >>>> broadcast 192.168.1.255
>> >>>> dns-nameservers 8.8.8.8 8.8.4.4
>> >>>>
>> >>>> Hope this helps.
>> >>>>
>> >>>> Allen
>> >>>>
>> >>>
>> >>> I've set my FE/BE reserved to .210 and the HDHRs to .211, and .212, no
>> >>> change to gateway and netmask, beyond this I need help.
>>
>> >>
>> >> What you did is not enough. I did that from day 1 and had the problem.
>> >> Perhaps you can ask a specific question based on the fix I posted.
>> >>
>> >>>
>> >>> OK Allen I'm all in, this is my interfaces file now:
>> > $ cat /etc/network/interfaces
>> ># interfaces(5) file used by ifup(8) and ifdown(8)
>> >auto lo
>> >iface lo inet loopback
>> >auto enp2s0
>> >iface enp2s0 inet static
>> > address 192.168.0.210
>> > netmask 255.255.255.0
>> > gateway 192.168.0.1
>> > broadcast 192.168.0.255
>> > dns-nameservers 8.8.8.8 8.8.4.4
>> >My only question is, where did you get the dns-nameservers values from? Do
>> >I need to edit these?
>>
>> You would normally want to use the nameservers that your router should
>> be getting from your ISP. Your router may be able to tell you what
>> they are. Using Google's public nameservers as above should work for
>> most things, but there can be some subtle problems (and benefits). For
>> example, if your ISP runs local CDN servers (say Akamai servers), then
>> anything you would normally have got from the local CDN servers will
>> now be received from some global server somewhere much further away if
>> you use Google DNS. And you may be unable to access ISP services that
>> are provided only to your ISP's customers from this PC.
>>
>> If you can find the correct ISP nameserver addresses from your router
>> of maybe from a web page on your ISP's help pages, or by calling their
>> helpdesk, then you can put them here. ISP nameserver addresses
>> normally do not change, but it can happen if they have to reorganise
>> their IP addresses (especially if someone takes them over), and if
>> that happens, then the static IPs that you put here will need to be
>> changed also. It is unlikely that your ISP will inform you if they
>> change the addresses, as your router will normally pick up the new
>> ones automatically. If you use Google's nameservers, then those
>> addresses are extremely unlikely to change. And if they ever do, it
>> will be big news on the Internet. But you are giving Google
>> information about what DNS addresses you are using.
>>
>> I think it may be possible to do partial DHCP, where you use a static
>> IP address as above, but get things like the nameserver addresses
>> using DHCP. I have never done that using the interfaces file, but it
>> is probably possible using some scripting. Likely way beyond your
>> capabilities.
>>
>> Also, using /etc/network/interfaces on a system that is using
>> NetworkManager as yours is, there can be lots of complications. I
>> found I had to disable NetworkManager to get some things to work, and
>> that may have included the "dns-nameservers" options. It is a very
>> long time ago that I did this, so my recollection is cloudy. So
>> overall I would recommend not doing static IP addresses this way
>> without removing NetworkManager. It gets too complicated.
>>
>> Instead, I would recommend that you use the NetworkManager GUI to set
>> a "Manual" IP address. "Manual" is NetworkManager's name for
>> "Static". You can then set the DNS options on the same screen to
>> "Automatic" and that will get the DNS server addresses using DHCP, but
>> have a static IP address. The best of both worlds, unless it was a
>> NetworkManager bug that was causing Allen's problems.
>>
>> Click on the NetworkManager icon, usually at the top of the screen,
>> often on the right somewhere. Mine looks like a little white box with
>> a line dropping down to two more little white boxes below it. Click
>> on the cogwheel icon to open the settings for the Ethernet card, then
>> on the "IPv4" tab. Select "IPv4 Method" "Manual" and fill in the
>> "Address" field with the static IP address you want. The "Netmask"
>> field should normally be set to "255.255.255.0" and the "Gateway" to
>> the IPv4 address of your router. Leave the "DNS" and "Routes" options
>> set to "Automatic". Click "Apply".
>> _________________________________________
>>
>
>I understand what you are saying Stephen, but I have a couple questions. If
>I go the manual method, would I first have to revert my
>"/etc/network/interfaces" file to original state? (I did get successful
>News and NFL recordings on HDHR last night) Secondly, I've employed a fix,
>recommended by this site "
>https://datawookie.netlify.com/blog/2018/10/dns-on-ubuntu-18.04/" to
>insure that nameserver settings required for my VPN survive a reboot. I
>assume this should be taken into account when using your's or Allen's fix,
>right?
>I just checked and the change to /etc/network/interfaces (Allen's fix) has
>not harmed my VPN usage.

OK, having set up those DNS settings for the VPN does change things.
You are already using non-ISP DNS servers, and what that fix does, in
a NetworkManager environment, likely overrides any "dns-nameservers"
lines in the interfaces file, if they were not already being ignored
by NetworkManager. So there is no need to change anything from what
you have. You might like to delete or comment out the
"dns-nameservers" line so that it does not fool you at some later date
into thinking that is the right place to change the nameserver
addresses.

Just be aware that if, at some later time, you want to use something
like an ISP provided multimedia service that is not available outside
the ISP network, it may not work on that PC with the non-ISP DNS
servers being used.
_______________________________________________
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

On Fri, Dec 13, 2019 at 7:28 AM Stephen Worthington <
stephen_agent@jsw.gen.nz> wrote:

> On Fri, 13 Dec 2019 09:51:00 -0500, you wrote:
>
> >On Fri, Dec 13, 2019 at 6:14 AM Stephen Worthington <
> >stephen_agent@jsw.gen.nz> wrote:
> >
> >> On Thu, 12 Dec 2019 16:31:02 -0500, you wrote:
> >>
> >> >On Thu, Dec 12, 2019 at 1:45 PM Allen Edwards <
> allen.p.edwards@gmail.com>
> >> >wrote:
> >> >
> >> >>
> >> >>
> >> >> On Thu, Dec 12, 2019, 10:29 AM Daryl McDonald <darylangela@gmail.com
> >
> >> >> wrote:
> >> >>
> >> >>>
> >> >>>
> >> >>> On Sat, Dec 7, 2019, 11:36 AM Allen Edwards <
> allen.p.edwards@gmail.com
> >> >
> >> >>> wrote:
> >> >>>
> >> >>>> I have no idea if this will be helpful but I had several issues
> >> getting
> >> >>>> my HDHR tuners to work. I provide these in case they might be
> useful.
> >> >>>>
> >> >>>> Myth address is 192.168.1.111 and is static. I set it as reserved
> on
> >> the
> >> >>>> router. I also set the HDHR addresses as reserved.
> >> >>>>
> >> >>>> I start the tuners from rc.local. Old school but works.
> >> >>>> Here is the code. I believe this was from the vendors website.
> >> >>>> hdhomerun_config 10137DC1 set /ir/target "192.168.1.111:5000
> >> no_clear"
> >> >>>> If you need to allow more time to go by, you can add a delay before
> >> this
> >> >>>> command.
> >> >>>>
> >> >>> This part is outside my capabilities, probably would need more time
> if
> >> I
> >> >>> get the mobo to play nice with ACPI.
> >> >>>
> >> >>>>
> >> >>>> I had a power supply issue as well. The module that I bought with
> the
> >> >>>> HDHR did not put out enough current so I got ones rated for more
> >> current.
> >> >>>>
> >> >>>> I also had random failures. The computer would lose contact with
> the
> >> >>>> turners every few weeks. I traced it to a linux problem as the
> tuners
> >> were
> >> >>>> still visible from a Windows computer on the same network. That
> >> >>>> troubleshooting tip was provided by Silicon Dust.
> >> >>>>
> >> >>>> Here is the solution.
> >> >>>>
> >> >>>> dad@NewMyth:~$ more /etc/network/interfaces
> >> >>>> # interfaces(5) file used by ifup(8) and ifdown(8)
> >> >>>> auto lo
> >> >>>> iface lo inet loopback
> >> >>>> auto enp2s0
> >> >>>> iface enp2s0 inet static
> >> >>>> address 192.168.1.111
> >> >>>> netmask 255.255.255.0
> >> >>>> gateway 192.168.1.1
> >> >>>> broadcast 192.168.1.255
> >> >>>> dns-nameservers 8.8.8.8 8.8.4.4
> >> >>>>
> >> >>>> Hope this helps.
> >> >>>>
> >> >>>> Allen
> >> >>>>
> >> >>>
> >> >>> I've set my FE/BE reserved to .210 and the HDHRs to .211, and .212,
> no
> >> >>> change to gateway and netmask, beyond this I need help.
> >>
> >> >>
> >> >> What you did is not enough. I did that from day 1 and had the
> problem.
> >> >> Perhaps you can ask a specific question based on the fix I posted.
> >> >>
> >> >>>
> >> >>> OK Allen I'm all in, this is my interfaces file now:
> >> > $ cat /etc/network/interfaces
> >> ># interfaces(5) file used by ifup(8) and ifdown(8)
> >> >auto lo
> >> >iface lo inet loopback
> >> >auto enp2s0
> >> >iface enp2s0 inet static
> >> > address 192.168.0.210
> >> > netmask 255.255.255.0
> >> > gateway 192.168.0.1
> >> > broadcast 192.168.0.255
> >> > dns-nameservers 8.8.8.8 8.8.4.4
> >> >My only question is, where did you get the dns-nameservers values
> from? Do
> >> >I need to edit these?
> >>
> >> You would normally want to use the nameservers that your router should
> >> be getting from your ISP. Your router may be able to tell you what
> >> they are. Using Google's public nameservers as above should work for
> >> most things, but there can be some subtle problems (and benefits). For
> >> example, if your ISP runs local CDN servers (say Akamai servers), then
> >> anything you would normally have got from the local CDN servers will
> >> now be received from some global server somewhere much further away if
> >> you use Google DNS. And you may be unable to access ISP services that
> >> are provided only to your ISP's customers from this PC.
> >>
> >> If you can find the correct ISP nameserver addresses from your router
> >> of maybe from a web page on your ISP's help pages, or by calling their
> >> helpdesk, then you can put them here. ISP nameserver addresses
> >> normally do not change, but it can happen if they have to reorganise
> >> their IP addresses (especially if someone takes them over), and if
> >> that happens, then the static IPs that you put here will need to be
> >> changed also. It is unlikely that your ISP will inform you if they
> >> change the addresses, as your router will normally pick up the new
> >> ones automatically. If you use Google's nameservers, then those
> >> addresses are extremely unlikely to change. And if they ever do, it
> >> will be big news on the Internet. But you are giving Google
> >> information about what DNS addresses you are using.
> >>
> >> I think it may be possible to do partial DHCP, where you use a static
> >> IP address as above, but get things like the nameserver addresses
> >> using DHCP. I have never done that using the interfaces file, but it
> >> is probably possible using some scripting. Likely way beyond your
> >> capabilities.
> >>
> >> Also, using /etc/network/interfaces on a system that is using
> >> NetworkManager as yours is, there can be lots of complications. I
> >> found I had to disable NetworkManager to get some things to work, and
> >> that may have included the "dns-nameservers" options. It is a very
> >> long time ago that I did this, so my recollection is cloudy. So
> >> overall I would recommend not doing static IP addresses this way
> >> without removing NetworkManager. It gets too complicated.
> >>
> >> Instead, I would recommend that you use the NetworkManager GUI to set
> >> a "Manual" IP address. "Manual" is NetworkManager's name for
> >> "Static". You can then set the DNS options on the same screen to
> >> "Automatic" and that will get the DNS server addresses using DHCP, but
> >> have a static IP address. The best of both worlds, unless it was a
> >> NetworkManager bug that was causing Allen's problems.
> >>
> >> Click on the NetworkManager icon, usually at the top of the screen,
> >> often on the right somewhere. Mine looks like a little white box with
> >> a line dropping down to two more little white boxes below it. Click
> >> on the cogwheel icon to open the settings for the Ethernet card, then
> >> on the "IPv4" tab. Select "IPv4 Method" "Manual" and fill in the
> >> "Address" field with the static IP address you want. The "Netmask"
> >> field should normally be set to "255.255.255.0" and the "Gateway" to
> >> the IPv4 address of your router. Leave the "DNS" and "Routes" options
> >> set to "Automatic". Click "Apply".
> >> _________________________________________
> >>
> >
> >I understand what you are saying Stephen, but I have a couple questions.
> If
> >I go the manual method, would I first have to revert my
> >"/etc/network/interfaces" file to original state? (I did get successful
> >News and NFL recordings on HDHR last night) Secondly, I've employed a fix,
> >recommended by this site "
> >https://datawookie.netlify.com/blog/2018/10/dns-on-ubuntu-18.04/" to
> >insure that nameserver settings required for my VPN survive a reboot. I
> >assume this should be taken into account when using your's or Allen's fix,
> >right?
> >I just checked and the change to /etc/network/interfaces (Allen's fix) has
> >not harmed my VPN usage.
>
> OK, having set up those DNS settings for the VPN does change things.
> You are already using non-ISP DNS servers, and what that fix does, in
> a NetworkManager environment, likely overrides any "dns-nameservers"
> lines in the interfaces file, if they were not already being ignored
> by NetworkManager. So there is no need to change anything from what
> you have. You might like to delete or comment out the
> "dns-nameservers" line so that it does not fool you at some later date
> into thinking that is the right place to change the nameserver
> addresses.
>
> Just be aware that if, at some later time, you want to use something
> like an ISP provided multimedia service that is not available outside
> the ISP network, it may not work on that PC with the non-ISP DNS
> servers being used.
> _______________________________________________
>
> Daryl, Good to hear you got it working. Stephen brings up some interesting
points. A little history. I got this fix from a combination of comments to
posts here by Ian Cameron, a bug report on Linux
https://bugs.launchpad.net/ubuntu/+source/avahi/+bug/1586528, and an
article I can't find. Stephen was also helpful in troubleshooting and in
particular eliminating the IPv6 issue as a possible cause. I reviewed the
thread and see that without the name servers the system appeared to work
but was not getting Schedules Direct data so after 2 seeks my recordings
stopped. I cannot find the article that suggested adding the name servers
but I am pretty sure I got it from a Google search. It did not come from
this group. I have static addresses or reserved addresses on the Linux box
and the HDHRs. I changed that as an experiment lately and it did not work.

Good to know, I commented out the nameserver line and will keep an eye on
the sched data.

On Fri, Dec 13, 2019, 11:05 AM Allen Edwards <allen.p.edwards@gmail.com>
wrote:

>
>
> On Fri, Dec 13, 2019 at 7:28 AM Stephen Worthington <
> stephen_agent@jsw.gen.nz> wrote:
>
>> On Fri, 13 Dec 2019 09:51:00 -0500, you wrote:
>>
>> >On Fri, Dec 13, 2019 at 6:14 AM Stephen Worthington <
>> >stephen_agent@jsw.gen.nz> wrote:
>> >
>> >> On Thu, 12 Dec 2019 16:31:02 -0500, you wrote:
>> >>
>> >> >On Thu, Dec 12, 2019 at 1:45 PM Allen Edwards <
>> allen.p.edwards@gmail.com>
>> >> >wrote:
>> >> >
>> >> >>
>> >> >>
>> >> >> On Thu, Dec 12, 2019, 10:29 AM Daryl McDonald <
>> darylangela@gmail.com>
>> >> >> wrote:
>> >> >>
>> >> >>>
>> >> >>>
>> >> >>> On Sat, Dec 7, 2019, 11:36 AM Allen Edwards <
>> allen.p.edwards@gmail.com
>> >> >
>> >> >>> wrote:
>> >> >>>
>> >> >>>> I have no idea if this will be helpful but I had several issues
>> >> getting
>> >> >>>> my HDHR tuners to work. I provide these in case they might be
>> useful.
>> >> >>>>
>> >> >>>> Myth address is 192.168.1.111 and is static. I set it as reserved
>> on
>> >> the
>> >> >>>> router. I also set the HDHR addresses as reserved.
>> >> >>>>
>> >> >>>> I start the tuners from rc.local. Old school but works.
>> >> >>>> Here is the code. I believe this was from the vendors website.
>> >> >>>> hdhomerun_config 10137DC1 set /ir/target "192.168.1.111:5000
>> >> no_clear"
>> >> >>>> If you need to allow more time to go by, you can add a delay
>> before
>> >> this
>> >> >>>> command.
>> >> >>>>
>> >> >>> This part is outside my capabilities, probably would need more
>> time if
>> >> I
>> >> >>> get the mobo to play nice with ACPI.
>> >> >>>
>> >> >>>>
>> >> >>>> I had a power supply issue as well. The module that I bought with
>> the
>> >> >>>> HDHR did not put out enough current so I got ones rated for more
>> >> current.
>> >> >>>>
>> >> >>>> I also had random failures. The computer would lose contact with
>> the
>> >> >>>> turners every few weeks. I traced it to a linux problem as the
>> tuners
>> >> were
>> >> >>>> still visible from a Windows computer on the same network. That
>> >> >>>> troubleshooting tip was provided by Silicon Dust.
>> >> >>>>
>> >> >>>> Here is the solution.
>> >> >>>>
>> >> >>>> dad@NewMyth:~$ more /etc/network/interfaces
>> >> >>>> # interfaces(5) file used by ifup(8) and ifdown(8)
>> >> >>>> auto lo
>> >> >>>> iface lo inet loopback
>> >> >>>> auto enp2s0
>> >> >>>> iface enp2s0 inet static
>> >> >>>> address 192.168.1.111
>> >> >>>> netmask 255.255.255.0
>> >> >>>> gateway 192.168.1.1
>> >> >>>> broadcast 192.168.1.255
>> >> >>>> dns-nameservers 8.8.8.8 8.8.4.4
>> >> >>>>
>> >> >>>> Hope this helps.
>> >> >>>>
>> >> >>>> Allen
>> >> >>>>
>> >> >>>
>> >> >>> I've set my FE/BE reserved to .210 and the HDHRs to .211, and
>> .212, no
>> >> >>> change to gateway and netmask, beyond this I need help.
>> >>
>> >> >>
>> >> >> What you did is not enough. I did that from day 1 and had the
>> problem.
>> >> >> Perhaps you can ask a specific question based on the fix I posted.
>> >> >>
>> >> >>>
>> >> >>> OK Allen I'm all in, this is my interfaces file now:
>> >> > $ cat /etc/network/interfaces
>> >> ># interfaces(5) file used by ifup(8) and ifdown(8)
>> >> >auto lo
>> >> >iface lo inet loopback
>> >> >auto enp2s0
>> >> >iface enp2s0 inet static
>> >> > address 192.168.0.210
>> >> > netmask 255.255.255.0
>> >> > gateway 192.168.0.1
>> >> > broadcast 192.168.0.255
>> >> > dns-nameservers 8.8.8.8 8.8.4.4
>> >> >My only question is, where did you get the dns-nameservers values
>> from? Do
>> >> >I need to edit these?
>> >>
>> >> You would normally want to use the nameservers that your router should
>> >> be getting from your ISP. Your router may be able to tell you what
>> >> they are. Using Google's public nameservers as above should work for
>> >> most things, but there can be some subtle problems (and benefits). For
>> >> example, if your ISP runs local CDN servers (say Akamai servers), then
>> >> anything you would normally have got from the local CDN servers will
>> >> now be received from some global server somewhere much further away if
>> >> you use Google DNS. And you may be unable to access ISP services that
>> >> are provided only to your ISP's customers from this PC.
>> >>
>> >> If you can find the correct ISP nameserver addresses from your router
>> >> of maybe from a web page on your ISP's help pages, or by calling their
>> >> helpdesk, then you can put them here. ISP nameserver addresses
>> >> normally do not change, but it can happen if they have to reorganise
>> >> their IP addresses (especially if someone takes them over), and if
>> >> that happens, then the static IPs that you put here will need to be
>> >> changed also. It is unlikely that your ISP will inform you if they
>> >> change the addresses, as your router will normally pick up the new
>> >> ones automatically. If you use Google's nameservers, then those
>> >> addresses are extremely unlikely to change. And if they ever do, it
>> >> will be big news on the Internet. But you are giving Google
>> >> information about what DNS addresses you are using.
>> >>
>> >> I think it may be possible to do partial DHCP, where you use a static
>> >> IP address as above, but get things like the nameserver addresses
>> >> using DHCP. I have never done that using the interfaces file, but it
>> >> is probably possible using some scripting. Likely way beyond your
>> >> capabilities.
>> >>
>> >> Also, using /etc/network/interfaces on a system that is using
>> >> NetworkManager as yours is, there can be lots of complications. I
>> >> found I had to disable NetworkManager to get some things to work, and
>> >> that may have included the "dns-nameservers" options. It is a very
>> >> long time ago that I did this, so my recollection is cloudy. So
>> >> overall I would recommend not doing static IP addresses this way
>> >> without removing NetworkManager. It gets too complicated.
>> >>
>> >> Instead, I would recommend that you use the NetworkManager GUI to set
>> >> a "Manual" IP address. "Manual" is NetworkManager's name for
>> >> "Static". You can then set the DNS options on the same screen to
>> >> "Automatic" and that will get the DNS server addresses using DHCP, but
>> >> have a static IP address. The best of both worlds, unless it was a
>> >> NetworkManager bug that was causing Allen's problems.
>> >>
>> >> Click on the NetworkManager icon, usually at the top of the screen,
>> >> often on the right somewhere. Mine looks like a little white box with
>> >> a line dropping down to two more little white boxes below it. Click
>> >> on the cogwheel icon to open the settings for the Ethernet card, then
>> >> on the "IPv4" tab. Select "IPv4 Method" "Manual" and fill in the
>> >> "Address" field with the static IP address you want. The "Netmask"
>> >> field should normally be set to "255.255.255.0" and the "Gateway" to
>> >> the IPv4 address of your router. Leave the "DNS" and "Routes" options
>> >> set to "Automatic". Click "Apply".
>> >> _________________________________________
>> >>
>> >
>> >I understand what you are saying Stephen, but I have a couple questions.
>> If
>> >I go the manual method, would I first have to revert my
>> >"/etc/network/interfaces" file to original state? (I did get successful
>> >News and NFL recordings on HDHR last night) Secondly, I've employed a
>> fix,
>> >recommended by this site "
>> >https://datawookie.netlify.com/blog/2018/10/dns-on-ubuntu-18.04/" to
>> >insure that nameserver settings required for my VPN survive a reboot. I
>> >assume this should be taken into account when using your's or Allen's
>> fix,
>> >right?
>> >I just checked and the change to /etc/network/interfaces (Allen's fix)
>> has
>> >not harmed my VPN usage.
>>
>> OK, having set up those DNS settings for the VPN does change things.
>> You are already using non-ISP DNS servers, and what that fix does, in
>> a NetworkManager environment, likely overrides any "dns-nameservers"
>> lines in the interfaces file, if they were not already being ignored
>> by NetworkManager. So there is no need to change anything from what
>> you have. You might like to delete or comment out the
>> "dns-nameservers" line so that it does not fool you at some later date
>> into thinking that is the right place to change the nameserver
>> addresses.
>>
>> Just be aware that if, at some later time, you want to use something
>> like an ISP provided multimedia service that is not available outside
>> the ISP network, it may not work on that PC with the non-ISP DNS
>> servers being used.
>> _______________________________________________
>>
>> Daryl, Good to hear you got it working. Stephen brings up some
> interesting points. A little history. I got this fix from a combination of
> comments to posts here by Ian Cameron, a bug report on Linux
> https://bugs.launchpad.net/ubuntu/+source/avahi/+bug/1586528, and an
> article I can't find. Stephen was also helpful in troubleshooting and in
> particular eliminating the IPv6 issue as a possible cause. I reviewed the
> thread and see that without the name servers the system appeared to work
> but was not getting Schedules Direct data so after 2 seeks my recordings
> stopped. I cannot find the article that suggested adding the name servers
> but I am pretty sure I got it from a Google search. It did not come from
> this group. I have static addresses or reserved addresses on the Linux box
> and the HDHRs. I changed that as an experiment lately and it did not work.
> _______________________________________________
> 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
>

On Fri, Dec 13, 2019 at 8:12 AM Daryl McDonald <darylangela@gmail.com>
wrote:

> Good to know, I commented out the nameserver line and will keep an eye on
> the sched data.
>

Why?

On Fri, Dec 13, 2019 at 11:25 AM Allen Edwards <allen.p.edwards@gmail.com>
wrote:

>
>
> On Fri, Dec 13, 2019 at 8:12 AM Daryl McDonald <darylangela@gmail.com>
> wrote:
>
>> Good to know, I commented out the nameserver line and will keep an eye on
>> the sched data.
>>
>
> Why?
> __________________________________________
>

As Stephen suggested, it may force longer routes global instead of
national. Easy enough to uncomment if I don't get data or have failures.
Did you find using google's nameservers was critical?

On Fri, Dec 13, 2019 at 8:29 AM Daryl McDonald <darylangela@gmail.com>
wrote:

>
>
> On Fri, Dec 13, 2019 at 11:25 AM Allen Edwards <allen.p.edwards@gmail.com>
> wrote:
>
>>
>>
>> On Fri, Dec 13, 2019 at 8:12 AM Daryl McDonald <darylangela@gmail.com>
>> wrote:
>>
>>> Good to know, I commented out the nameserver line and will keep an eye
>>> on the sched data.
>>>
>>
>> Why?
>> __________________________________________
>>
>
> As Stephen suggested, it may force longer routes global instead of
> national. Easy enough to uncomment if I don't get data or have failures.
> Did you find using google's nameservers was critical?
> _______________________________________________
>
>
I just switched my router setting to use the Google servers and they seem
to work better but not a very scientific test. What I found was that
putting in the name servers was critical and I didn't give it a lot of
thought. Google name servers are world wide and distributed. I would say it
is likely that the Google name servers will be faster than the ones you are
using. At a minimum, you probably cannot prove that is not the case.
https://developers.google.com/speed/public-dns/docs/performance#geography

On Fri, Dec 13, 2019 at 11:43 AM Allen Edwards <allen.p.edwards@gmail.com>
wrote:

>
>
> On Fri, Dec 13, 2019 at 8:29 AM Daryl McDonald <darylangela@gmail.com>
> wrote:
>
>>
>>
>> On Fri, Dec 13, 2019 at 11:25 AM Allen Edwards <allen.p.edwards@gmail.com>
>> wrote:
>>
>>>
>>>
>>> On Fri, Dec 13, 2019 at 8:12 AM Daryl McDonald <darylangela@gmail.com>
>>> wrote:
>>>
>>>> Good to know, I commented out the nameserver line and will keep an eye
>>>> on the sched data.
>>>>
>>>
>>> Why?
>>> __________________________________________
>>>
>>
>> As Stephen suggested, it may force longer routes global instead of
>> national. Easy enough to uncomment if I don't get data or have failures.
>> Did you find using google's nameservers was critical?
>> _______________________________________________
>>
>>
> I just switched my router setting to use the Google servers and they seem
> to work better but not a very scientific test. What I found was that
> putting in the name servers was critical and I didn't give it a lot of
> thought. Google name servers are world wide and distributed. I would say it
> is likely that the Google name servers will be faster than the ones you are
> using. At a minimum, you probably cannot prove that is not the case.
> https://developers.google.com/speed/public-dns/docs/performance#geography
>
> ____________________
>

Fair enough,and as a further test, because there was not a rebboot
following the changes, I uncommented the nameservers and rebooted and VPN
still works, so nameservers stay in, unless symptoms dictate otherwise.
thank-you Allen for your persistant belief in this fix. Daryl

On Fri, Dec 13, 2019 at 9:38 AM Daryl McDonald <darylangela@gmail.com>
wrote:

>
>
> On Fri, Dec 13, 2019 at 11:43 AM Allen Edwards <allen.p.edwards@gmail.com>
> wrote:
>
>>
>>
>> On Fri, Dec 13, 2019 at 8:29 AM Daryl McDonald <darylangela@gmail.com>
>> wrote:
>>
>>>
>>>
>>> On Fri, Dec 13, 2019 at 11:25 AM Allen Edwards <
>>> allen.p.edwards@gmail.com> wrote:
>>>
>>>>
>>>>
>>>> On Fri, Dec 13, 2019 at 8:12 AM Daryl McDonald <darylangela@gmail.com>
>>>> wrote:
>>>>
>>>>> Good to know, I commented out the nameserver line and will keep an eye
>>>>> on the sched data.
>>>>>
>>>>
>>>> Why?
>>>> __________________________________________
>>>>
>>>
>>> As Stephen suggested, it may force longer routes global instead of
>>> national. Easy enough to uncomment if I don't get data or have failures.
>>> Did you find using google's nameservers was critical?
>>> _______________________________________________
>>>
>>>
>> I just switched my router setting to use the Google servers and they seem
>> to work better but not a very scientific test. What I found was that
>> putting in the name servers was critical and I didn't give it a lot of
>> thought. Google name servers are world wide and distributed. I would say it
>> is likely that the Google name servers will be faster than the ones you are
>> using. At a minimum, you probably cannot prove that is not the case.
>> https://developers.google.com/speed/public-dns/docs/performance#geography
>>
>> ____________________
>>
>
> Fair enough,and as a further test, because there was not a rebboot
> following the changes, I uncommented the nameservers and rebooted and VPN
> still works, so nameservers stay in, unless symptoms dictate otherwise.
> thank-you Allen for your persistant belief in this fix. Daryl
> _______________________________________________
>
> You are welcome.

On Fri, Dec 13, 2019 at 12:37 PM Daryl McDonald <darylangela@gmail.com>
wrote:

>
>
> On Fri, Dec 13, 2019 at 11:43 AM Allen Edwards <allen.p.edwards@gmail.com>
> wrote:
>
>>
>>
>> On Fri, Dec 13, 2019 at 8:29 AM Daryl McDonald <darylangela@gmail.com>
>> wrote:
>>
>>>
>>>
>>> On Fri, Dec 13, 2019 at 11:25 AM Allen Edwards <
>>> allen.p.edwards@gmail.com> wrote:
>>>
>>>>
>>>>
>>>> On Fri, Dec 13, 2019 at 8:12 AM Daryl McDonald <darylangela@gmail.com>
>>>> wrote:
>>>>
>>>>> Good to know, I commented out the nameserver line and will keep an eye
>>>>> on the sched data.
>>>>>
>>>>
>>>> Why?
>>>> __________________________________________
>>>>
>>>
>>> As Stephen suggested, it may force longer routes global instead of
>>> national. Easy enough to uncomment if I don't get data or have failures.
>>> Did you find using google's nameservers was critical?
>>> _______________________________________________
>>>
>>>
>> I just switched my router setting to use the Google servers and they seem
>> to work better but not a very scientific test. What I found was that
>> putting in the name servers was critical and I didn't give it a lot of
>> thought. Google name servers are world wide and distributed. I would say it
>> is likely that the Google name servers will be faster than the ones you are
>> using. At a minimum, you probably cannot prove that is not the case.
>> https://developers.google.com/speed/public-dns/docs/performance#geography
>>
>> ____________________
>>
>
> Fair enough,and as a further test, because there was not a rebboot
> following the changes, I uncommented the nameservers and rebooted and VPN
> still works, so nameservers stay in, unless symptoms dictate otherwise.
> thank-you Allen for your persistant belief in this fix. Daryl
>

Allen, can you also explain what your old school start on rc is all about,
it may not matter but I'm curious. Mine are plugged into a smart bar, in
that they shut down and power up with the PC.

On Fri, Dec 13, 2019 at 9:46 AM Daryl McDonald <darylangela@gmail.com>
wrote:

>
>
> On Fri, Dec 13, 2019 at 12:37 PM Daryl McDonald <darylangela@gmail.com>
> wrote:
>
>>
>>
>> On Fri, Dec 13, 2019 at 11:43 AM Allen Edwards <allen.p.edwards@gmail.com>
>> wrote:
>>
>>>
>>>
>>> On Fri, Dec 13, 2019 at 8:29 AM Daryl McDonald <darylangela@gmail.com>
>>> wrote:
>>>
>>>>
>>>>
>>>> On Fri, Dec 13, 2019 at 11:25 AM Allen Edwards <
>>>> allen.p.edwards@gmail.com> wrote:
>>>>
>>>>>
>>>>>
>>>>> On Fri, Dec 13, 2019 at 8:12 AM Daryl McDonald <darylangela@gmail.com>
>>>>> wrote:
>>>>>
>>>>>> Good to know, I commented out the nameserver line and will keep an
>>>>>> eye on the sched data.
>>>>>>
>>>>>
>>>>> Why?
>>>>> __________________________________________
>>>>>
>>>>
>>>> As Stephen suggested, it may force longer routes global instead of
>>>> national. Easy enough to uncomment if I don't get data or have failures.
>>>> Did you find using google's nameservers was critical?
>>>> _______________________________________________
>>>>
>>>>
>>> I just switched my router setting to use the Google servers and they
>>> seem to work better but not a very scientific test. What I found was that
>>> putting in the name servers was critical and I didn't give it a lot of
>>> thought. Google name servers are world wide and distributed. I would say it
>>> is likely that the Google name servers will be faster than the ones you are
>>> using. At a minimum, you probably cannot prove that is not the case.
>>> https://developers.google.com/speed/public-dns/docs/performance#geography
>>>
>>> ____________________
>>>
>>
>> Fair enough,and as a further test, because there was not a rebboot
>> following the changes, I uncommented the nameservers and rebooted and VPN
>> still works, so nameservers stay in, unless symptoms dictate otherwise.
>> thank-you Allen for your persistant belief in this fix. Daryl
>>
>
> Allen, can you also explain what your old school start on rc is all about,
> it may not matter but I'm curious. Mine are plugged into a smart bar, in
> that they shut down and power up with the PC.
>
>
Well, I started with Mythbuntu 8 and ran that for many years until a disk
crash. The switch to Mythbuntu 18 was painful and I got a ton of help from
Stephen and others. Doing the initialization of the HDHRs the way I do was
just how I always did it. The bigger issue I had was with getting the
optical remote to work with the new OS. I don't recall if I posted the
entire script but it does more than just manage the HDHRs. I had no
interest in finding a new way to get the power control to work and once I
got the remote working I was happy. There are apparently lots of concerns
about the way I do it as there are potential problems I don't understand or
have. My goal was to get a working system and I am almost there. I still
have the x server lock up every few months but other than that, it is
perfect.

Here is my entire rc.local script. Note the hack. I need to start lircd for
the HDHR but something is starting it first. Ideally I would either stop it
from doing that or modify what it is doing perhaps putting the HDHR code
there but I could not find it and this works fine. Not elegant but as I
recall, you had some issue with the timing of how things come up so this
old school approach might help you with that. If you need more time for
something to come up before initializing the hdhr, just do it this way. I
believe that rc.local is run last and you can put a delay in the script if
you need to.

echo -n 15 > /sys/devices/system/cpu/cpufreq/ondemand/up_threshold
hdhomerun_config 10137DC1 set /ir/target "192.168.1.111:5000 no_clear"
#this is a hack. I don't know what is starting lircd
killall lircd
lircd -H udp -d 5000


exit 0