Mailing List Archive

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.

>
>