[mythtv-users] Many programs not getting any commercial detection

[Mark Knecht]

On Mon, Sep 22, 2008 at 7:24 PM, Roger Heflin <rogerheflin at gmail.com> wrote:
> Mark Knecht wrote:
>>
>> The other thing I'm seeing, looking in dmesg on the backend server, is
>> that mythfilldatabase is dying:
>>
>> mythfilldatabas[9592] general protection eip:81ade99 esp:b4612245 error:0
>> mythfilldatabas[12508]: segfault at 86819ff0 eip 081ba3a0 esp b466cc8c error 4
>> i2c-adapter i2c-1: sendbytes: error - bailout.
>> msp3400 1-0040: I/O error #0 (read 0x10/0x200)
>> i2c-adapter i2c-1: sendbytes: error - bailout.
>> msp3400 1-0040: I/O error #0 (read 0x10/0x200)
>> mythfilldatabas[13848]: segfault at 0000f4df eip 081ba51b esp b4605c8c error 6
>> i2c-adapter i2c-1: sendbytes: error - bailout.
>> msp3400 1-0040: I/O error #0 (read 0x10/0x200)
>> i2c-adapter i2c-1: sendbytes: error - bailout.
>> msp3400 1-0040: I/O error #0 (read 0x10/0x200)
>> mythfilldatabas[15732]: segfault at 884db733 eip 081ba588 esp b46dac8c error 6
>>
>> Running it by hand seems to work but I get a segfalt message at the
>> end so I don't know what's wrong. It's Gentoo based so I'll look at
>> doing updates I guess.
>>
>> There seem to be some pretty serious problems here. Not good.
>
> It has been doing that for a while.    I am on fedora 7 and the newer kernels
> started logging the improper segfaults of programs in the messages file, I would
> bet that mythfilldatabas has been segfaulting for a while (maybe a long while or
> possibly always) and since it was doing the job correctly no one noticed that it
> was segfaulting...until the kernel starting logging program segfaults in the log
> file.    I have been having several a day since around May 1, and so far the
> database appears to be properly updating the entire time, so whatever it is that
> is broken is not broken enough to be lethal.
>
>                                 Roger

I agree that it's not lethal. Even though this is happening we always
seem to have 2 weeks worth of programs in the schedules.

Thanks,
Mark