<div class="gmail_quote">On Mon, Feb 9, 2009 at 6:47 PM, Jelte Veldstra <span dir="ltr"><<a href="mailto:jelte.veldstra@gmail.com">jelte.veldstra@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div><div></div><div class="h5"><div class="gmail_quote">On Mon, Feb 9, 2009 at 5:53 PM, Bruce Taber <span dir="ltr"><<a href="mailto:b.taber@comcast.net" target="_blank">b.taber@comcast.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div>Jelte Veldstra wrote:<br>
> Hello Bruce,<br>
><br>
> Thanks for your input. What led you to this conclusion and what Ethernet<br>
> chip was the faulty one? My PCI slots are taken so I cannot easily try<br>
> it myself. Where there messages in logfiles that hinted issues with the<br>
> Ethernet port or was the Ethernet traffic poor? I have already replaced<br>
> this motherboard (for different reasons) and it now has a different<br>
> Ethernet chip. As far as I can tell it's working just fine, but perhaps<br>
> there are conflicts with certain chips.<br>
><br>
> Regards,<br>
><br>
><br>
> Jelte<br>
><br>
><br>
><br>
</div><div>> ------------------------------------------------------------------------<br>
><br>
> _______________________________________________<br>
> mythtv-users mailing list<br>
> <a href="mailto:mythtv-users@mythtv.org" target="_blank">mythtv-users@mythtv.org</a><br>
> <a href="http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users" target="_blank">http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users</a><br>
</div>On my system there were no entries in any of the log files. The only<br>
indications were odd speeds (seen by much higher readings than<br>
physically possible) during scp transfers. Putting pressure on the<br>
Ethernet port by increasing the amount of traffic either with mythtv<br>
streaming or with the scp caused the system to lockup more often.<br>
However, it wasn't guaranteed to trigger the problem.<br>
<br>
I also did not have an extra slot and eventually removed one of the<br>
tuner cards to make room. I found the problem by general troubleshooting<br>
steps of removing one card at a time. The whole mess was far more<br>
complicated and delayed because I found a bad memory module and also<br>
thought I had messed up the system with an upgrade. It would run for up<br>
to 3 days before just randomly stopping dead in its tracks with no<br>
console output nor log entries. It was very frustrating until finally<br>
putting in the replacement Ethernet card. Everything has been running<br>
normally since then which is a few months now.<br>
<div><div></div><div><br>
Bruce<br>
_______________________________________________<br>
mythtv-users mailing list<br>
<a href="mailto:mythtv-users@mythtv.org" target="_blank">mythtv-users@mythtv.org</a><br>
<a href="http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users" target="_blank">http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users</a><br>
</div></div></blockquote></div><br><br></div></div>Thanks again for your input. I appreciate that you take time for this. The fileserver tasks this backend does also work just fine. Network performance is what I'd expect from a Gbit link. Doing lots of network and disk IO has never brought it on its knees. I've also done four concurrent recordings with it (using multirec). So based on your feedback there is no need yet to suspect the hardware is intermittently failing.<br>
<br>I agree that these things can be hard to track down. In my case it happens maybe once a month. It's not reproducable so far, so that makes it even harder to nail it down.<br><br>Regards,<br><font color="#888888"><br>
<br>Jelte<br>
</font></blockquote></div><br><br>Update: I may have found out what made my system crash. Here's the long
story that leads me to this (premature?) conclusion - added for
whomever searching this list with similar experiences and wondering
whether it was solved:<br>
<br>
As the system only crashed at the start of the recordings there had to
be something wrong in the recording chain and I decided to wipe all
tuners and inputs from the system and add them one by one without
multirec enabled (just to be sure that multirec was to blame here).
This worked very well for weeks. The system ran for weeks without
crashing and none of the recordings failed or turned into zero byte
recordings. To me this was further proof that the hardware was not
flakey.<br>
<br>
The only thing I didn't like was that when watching LiveTV (we still
use it...) it would default to the tuner that doesn't have the whole
range of channels. I set avoid conflicts when watching LiveTV so that
the other tuner that has 80% of the channels was avoided ( I raised
it's priority so that that was more likely to be used for recordings).
As that didn't work as expected I found that the avoid conflict feautre
only works based on the inputid. So to get it to work I had to change
the inputids. Being cocky as I am I decided to backup the database and
manually change these ids. While I was at it I decided to change the
cardids as well so my encoders would be numbered 1 and 2 again rather
then 6 and 7. I thought I found all required tables and made changes
where necessary and initial tests worked just fine. Later that night
the first crash since weeks manifested itself followed by a second
within 12 hours.<br>
<br>
Now that had to be related to my direct MySQL edits in other words
"user error". Digging through the steps once more I could not see what
part I had missed all references from one table to another seemed to
match. Then I ran mythtv-setup again and found references to
inputgroups. That was a setting I had never set myself. As far as I can
see these were remnants from multirec settings used in the past.
Emptying the inputgroup table seems to have solved the issue as from
there all seems to be stable again. <br>
<br>
My hunch now is that as I manually changed the inputids. They matched
with inputgroup settings I wasn't aware of. However those inputgroups
settings were pointing to non-existant references of previous tuner
setups. These loose ends probably caused the driver to be triggered in
such a way that it made the system halt. There should never be a reason
to halt the system, so that may be a bug of some kind. I would expect
that recordings fail or maybe the mythbackend process to die. I totally
take responsibility for the fact that I manually changed MySQL records
and thus caused references to get out of sync.<br>
<br>
I'll keep using the system and in a couple of weeks I can really
conclude whether the stability has returned now the conflicting
inputgroup references are taken out. If I find time this weekend I may
restore some of the conflicting entries once more to see if it indeed
causes these crashes.<br>