[mythtv-commits] Ticket #10414: HDHomeRun: Bad Recordings

[MythTV]

#10414: HDHomeRun: Bad Recordings
------------------------------------------------+--------------------------
 Reporter:  Billy Macdonald <billymacdonald@…>  |          Owner:  danielk
     Type:  Bug Report - General                |         Status:  accepted
 Priority:  minor                               |      Milestone:  0.26
Component:  MythTV - Recording                  |        Version:  Master
 Severity:  medium                              |  Head
 Keywords:                                      |     Resolution:
                                                |  Ticket locked:  0
------------------------------------------------+--------------------------

Comment (by David Walker <David@…>):

 I've compiled a new mythbackend with the 20120405 version of libhdhomerun
 and ran it with net.core.rmem_max = 1048576.  This improved things, but it
 was only a compensation, as spartacus06 said.  Mythbackend's log still
 reported gaps in recorded programs.

 While waiting for compiles, though, I did some packet traces with tcpdump
 and noticed something pretty suspicious.  While a recording is in
 progress, there are long, uninterrupted strings of 1328-byte UDP packets,
 as expected.  A few seconds before the start of a recording gap, though,
 the HDHomeRun Prime starts sending ARP requests for the MythTV server once
 a second.  The server responds to each of the ARP requests.  After a few
 seconds, the UDP stream stops, causing the recording gap.  While the UDP
 stream stops, the once-a-second ARP requests continue.  I'll attach a
 tcpdump output file (tcp.log.gz) showing this behavior; I've edited long
 runs of the UDP packets out, as you will see in the file.

 I could see that the ARP requests stopped eventually, and I had a hunch
 that they stopped when the HDHomeRun Prime received a unicast packet from
 the MythTV server, so I tried running

   ping -q -n <HDHomeRun Prime address>

 from the server to generate a once-a-second stream of unicast ping
 packets.  I scheduled several recordings, and no gaps!  Then I reverted to
 the Packman version of mythbackend and the standard default for
 net.core.rmem_max (114688), but left the ping running.  Still no
 recordings gaps.  The once-per-second ARP requests still occur, but the
 pings seem to keep the UDP stream going.

 So, I think the HDHomeRun Prime has an issue.  It may be aggravated by
 something that MythTV is doing, but it looks like a bug in the HDHomeRun
 network code to me.

 Is someone from SiliconDust following this?  Is this known behavior?

-- 
Ticket URL: <http://code.mythtv.org/trac/ticket/10414#comment:25>
MythTV <http://code.mythtv.org/trac>
MythTV Media Center