[mythtv-users] System crashes on start of DVB-S recording

[Jelte Veldstra]

On Mon, Feb 9, 2009 at 6:47 PM, Jelte Veldstra <jelte.veldstra at gmail.com>wrote:

> On Mon, Feb 9, 2009 at 5:53 PM, Bruce Taber <b.taber at comcast.net> wrote:
>
>> Jelte Veldstra wrote:
>> > Hello Bruce,
>> >
>> > Thanks for your input. What led you to this conclusion and what Ethernet
>> > chip was the faulty one? My PCI slots are taken so I cannot easily try
>> > it myself. Where there messages in logfiles that hinted issues with the
>> > Ethernet port or was the Ethernet traffic poor? I have already replaced
>> > this motherboard (for different reasons) and it now has a different
>> > Ethernet chip. As far as I can tell it's working just fine, but perhaps
>> > there are conflicts with certain chips.
>> >
>> > Regards,
>> >
>> >
>> > Jelte
>> >
>> >
>> >
>> > ------------------------------------------------------------------------
>> >
>> > _______________________________________________
>> > mythtv-users mailing list
>> > mythtv-users at mythtv.org
>> > http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users
>> On my system there were no entries in any of the log files. The only
>> indications were odd speeds (seen by much higher readings than
>> physically possible) during scp transfers. Putting pressure on the
>> Ethernet port by increasing the amount of traffic either with mythtv
>> streaming or with the scp caused the system to lockup more often.
>> However, it wasn't guaranteed to trigger the problem.
>>
>> I also did not have an extra slot and eventually removed one of the
>> tuner cards to make room. I found the problem by general troubleshooting
>> steps of removing one card at a time. The whole mess was far more
>> complicated and delayed because I found a bad memory module and also
>> thought I had messed up the system with an upgrade. It would run for up
>> to 3 days before just randomly stopping dead in its tracks with no
>> console output nor log entries. It was very frustrating until finally
>> putting in the replacement Ethernet card. Everything has been running
>> normally since then which is a few months now.
>>
>> Bruce
>> _______________________________________________
>> mythtv-users mailing list
>> mythtv-users at mythtv.org
>> http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users
>>
>
>
> 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.
>
> 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.
>
> Regards,
>
>
> Jelte
>


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:

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.

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.

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.

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.

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mythtv.org/pipermail/mythtv-users/attachments/20090320/d74c6272/attachment.htm>