[mythtv-users] HDHR prob with new wallwarts

[Stephen Worthington]

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

>On Sat, Dec 7, 2019 at 11:17 PM Stephen Worthington <
>stephen_agent at 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.