[mythtv-commits] Ticket #13121: Sat>IP client support
MythTV
noreply at mythtv.org
Sun Nov 29 18:46:56 UTC 2020
#13121: Sat>IP client support
--------------------------------+-------------------------------
Reporter: cg@… | Owner: Klaas de Waal
Type: Patch - Feature | Status: assigned
Priority: minor | Milestone: 32.0
Component: MythTV - Recording | Version: Master Head
Severity: low | Resolution:
Keywords: | Ticket locked: 0
--------------------------------+-------------------------------
Comment (by Klaas de Waal):
Thanks for reporting back.
About the UDP buffer size. I've looked in the HDHomeRun library and there
the UDP buffer size is set to 1024x1024 bytes, the actual value depending
on the net.core.rmem_max value of the system. Note that it overall saves
memory if you only set the net.core.rmem_max value and not the
net.core.rmem_default because MythTV only extends the buffer size for the
socket that is actually used for the video data stream. There is also a
socket for the control data and the buffer size of that socket does not
need to be changed.
I've looked into the "bad patch" problem and this is caused by the
multirec feature not yet being implemented completely. What happens is
that when your second recording starts the box is tuned again, on the same
channel. This causes the disruption in your first recording. The correct
behavior is to recognize that the channel is already in use and that it is
already correctly tuned so the tuning can be skipped.
This is how it is implemented for the /dev/dvb/adapter*/* devices
(PCI/PCIe, USB) and this is also how it should be done for SatIP.
About the bitrate of the incoming stream. The code is now such that when
more than 32 PIDs are requested the full transport stream is received.
When there are less PIDs requested then the Sat>IP box is doing the PID
filtering so then you only receive the PIDs that are needed.
This is done because the Digibit R1 box effectively dies when your request
more than 36 or 37 PIDs. The minisatip software, running on a PC, does not
have this limitation but we write software for the worst case situation.
Still to investigate why recording a channel on the BBC One/Two HD mux
requires so many PIDS that it needs to receive the full transport stream.
--
Ticket URL: <https://code.mythtv.org/trac/ticket/13121#comment:45>
MythTV <http://www.mythtv.org>
MythTV Media Center
More information about the mythtv-commits
mailing list