[mythtv-users] HDHR prob with new wallwarts

[Silicondust]

On Sat, Dec 7, 2019 at 7:56 PM Silicondust <mythtv at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mythtv.org/pipermail/mythtv-users/attachments/20191207/ef3c3d22/attachment.htm>