<br><br><div class="gmail_quote">On Sat, Nov 17, 2012 at 11:34 AM, Mario Limonciello <span dir="ltr"><<a href="mailto:mario.mailing@gmail.com" target="_blank">mario.mailing@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">On Fri, Nov 16, 2012 at 12:39 PM, Brian Phillips <span dir="ltr"><<a href="mailto:brian.phillips@byu.net" target="_blank">brian.phillips@byu.net</a>></span> wrote:<br></div><div class="gmail_quote"><div class="im">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>Mark Greenwood wrote:<br>
> Something I noticed is that that setting appears to be screwing<br>
> really badly with the performance of my NFS shares and SSH<br>
> connections to my myth box. Disabling it seems to have cured the<br>
> problems I was having. I say seems to as it's only been a day, but<br>
> I've so far noticed none of the regular pauses I used to have during<br>
> SSH connections or when transferring files via NFS.<br>
><br>
> Mark<br>
<br>
</div>Very interesting, I'll watch for that.<br>
<br>
Reading the ticket more in-depth, I noticed Mythbuntu 12.04 is not using the<br>
same version of libhdhomerun as mentioned in the ticket. I went and grabbed<br>
the libhdhomerun from 12.10 and installed it and will monitor any changes in<br>
the performance.<br><br></blockquote></div><div>libhdhomerun is actually included directly in mythtv and compiled as libmythhdhomerun. So grabbing a newer libhdhomerun will only actually help hdhomerun_config_gui and hdhomerun_config.</div>
<div><br></div><div>That being said I have the same problem as described here even with the rbuf_max change in the packages. I chatted a little bit with a SD rep in their IRC channel. They haven't been able to reproduce it themselves but have gotten a lot of reports from *buntu users and some fedora users.</div>
<div><br></div><div>He says it's most likely a firmware issue.</div><div><br></div><div>Current working theory from SD is that nothing on the myth box is responding to SSDP requests from the HDHR. Normally W7/W8 WMC will respond to these requests. When they did their testing for Linux they didn't encounter it maybe because W7/W8 WMC are still on the network and speaking to the HDHR even if it's just control/status signals while the Linux box is recording.</div>
<div><br></div><div>All that said, I put this upstart job in place and it seems to have at least helped the last two nights of recordings that I was previously encountering problems. It's basically leveraging that workaround that was mentioned in the ticket on every boot.</div>
<div><br></div><div><div>#Ping of Death, by mario limonciello</div><div>#workaround for <a href="http://code.mythtv.org/trac/ticket/10414" target="_blank">http://code.mythtv.org/trac/ticket/10414</a></div><div>#and <a href="http://www.silicondust.com/forum/viewtopic.php?t=13227" target="_blank">http://www.silicondust.com/forum/viewtopic.php?t=13227</a></div>
<div><br></div><div>description "endlessly ping a HDHR prime"</div><div><br></div><div>start on net-device-up IFACE!=lo</div><div><br></div><div>script</div><div> ID=$(hdhomerun_config discover | awk '{ print $6 }')</div>
<div> ping -i 1 -n $ID > /dev/null</div><div>end script</div></div><br></div></blockquote><div><br><br>Breaks with more than one HDHR (I think it will anyway) <br></div></div>