[mythtv-users] Random lockups on Mythbackend

[dwoody1]

Joe wrote:
> On Mon, Dec 20, 2010 at 2:16 PM, dwoody1 <dwoody1 at charter.net> wrote:
>> Brian Wood wrote:
>>>> I record OTA and Mythtv shows 720, 1080, HD and sometimes blank. But,
>>>> we live in Texas, so I assume it is all digital if that makes a
>>>> difference.
>>> So we're talking about HD. I suspect your CPU is not capable of that much
>>> activity with HD, especially since you are using software decoding.
> 
> Years ago I was running a frontend based on on a single-core sempron.
> Can't remember the clock rate, but it wasn't high.  It would barely
> keep up with decoding HD in software; the CPU would be running over
> 90% constantly while playing 1080i, slightly less for 720p but still
> quite high.  This was all captured OTA using pcHDTV 5500 cards.
> 
> But the point is that it DID keep up, so your athlon X2 should be
> handling it without a problem.  As long as you have proper cooling and
> hardware that works, a cpu can be pegged at 100% all day and never
> lock up.
> 
>>>> I have been using the HDMI output. I thought that used less cpu than
>>>> using VGA output. But perhaps still too much.
>>> I wasn't aware that HDMI made any difference in CPU usage, first I had
>>> heard of that.
>> I read some where that with the HDMI output the computer did not have to
>> convert to analog, which would take more processing. Do not really know
>> if this is true or not.
> 
> The part about there being no analog conversion is true, but it is all
> handled in hardware by the video card and it makes no difference in
> CPU usage.  HDMI is just a connection type.
> 
>>>> If so, from your comments above, a VDPAU-capable video card would be
>>>> called for. From your experience, are there cards that you would
>>>> recommend or avoid?
>>>> From comments here and other places I'd go with an nVidia GT220 or 240,
>>> they are reasonably priced and seem to work well.
> 
> Personally, I wouldn't jump to conclusions about the video card and go
> upgrading it unnecessarily.  If you have the cpu power to do software
> decoding then it is perfectly fine, and in some cases even better to
> just use that.
> 
> Your problem definitely sounds like faulty hardware and it seems like
> you may have already found the problem w/the mce usb receiver.  After
> replacing that, long as your system is stable and you are not having
> problems that are actually traceable to lack of free CPU cycles, why
> mess with it?

The remote control was not the problem after all. My most recent test is 
to move the hard drive and tuner card (pcHDTV 5500) to another computer 
  to see if the problem goes away. This computer was upgraded about 7 
months ago and has worked flawlessly ever since. The computer crashed a 
few minutes ago.  The messages log file had the following just before 
the crash.

Jan 25 14:55:07 star9 kernel: sr 6:0:1:0: [sr0] Result: hostbyte=DID_OK 
driverbyte=DRIVER_SENSE
Jan 25 14:55:07 star9 kernel: sr 6:0:1:0: [sr0] Sense Key : Illegal 
Request [current]
Jan 25 14:55:07 star9 kernel: sr 6:0:1:0: [sr0] Add. Sense: Read of 
scrambled sector without authentication
Jan 25 14:55:07 star9 kernel: sr 6:0:1:0: [sr0] CDB: Read(10): 28 00 00 
00 04 00 00 00 02 00
Jan 25 14:55:07 star9 kernel: end_request: I/O error, dev sr0, sector 4096
Jan 25 14:55:07 star9 kernel: Buffer I/O error on device sr0, logical 
block 1024
Jan 25 14:55:07 star9 kernel: Buffer I/O error on device sr0, logical 
block 1025
Jan 25 14:55:07 star9 kernel: sr 6:0:1:0: [sr0] Result: hostbyte=DID_OK 
driverbyte=DRIVER_SENSE
Jan 25 14:55:07 star9 kernel: sr 6:0:1:0: [sr0] Sense Key : Illegal 
Request [current]
Jan 25 14:55:07 star9 kernel: sr 6:0:1:0: [sr0] Add. Sense: Read of 
scrambled sector without authentication
Jan 25 14:55:07 star9 kernel: sr 6:0:1:0: [sr0] CDB: Read(10): 28 00 00 
00 04 00 00 00 02 00
Jan 25 14:55:07 star9 kernel: end_request: I/O error, dev sr0, sector 4096
Jan 25 14:55:07 star9 kernel: Buffer I/O error on device sr0, logical 
block 1024
Jan 25 14:55:07 star9 kernel: Buffer I/O error on device sr0, logical 
block 1025
Jan 25 14:55:07 star9 kernel: sr 6:0:1:0: [sr0] Result: hostbyte=DID_OK 
driverbyte=DRIVER_SENSE
Jan 25 14:55:07 star9 kernel: sr 6:0:1:0: [sr0] Sense Key : Illegal 
Request [current]
Jan 25 14:55:07 star9 kernel: sr 6:0:1:0: [sr0] Add. Sense: Read of 
scrambled sector without authentication
Jan 25 14:55:07 star9 kernel: sr 6:0:1:0: [sr0] CDB: Read(10): 28 00 00 
00 04 00 00 00 02 00
Jan 25 14:55:07 star9 kernel: end_request: I/O error, dev sr0, sector 4096
Jan 25 14:55:07 star9 kernel: Buffer I/O error on device sr0, logical 
block 1024
Jan 25 14:55:07 star9 kernel: Buffer I/O error on device sr0, logical 
block 1025

Then on boot up.
Jan 25 16:00:30 star9 kernel: imklog 4.4.2, log source = /proc/kmsg started.

Does it make any sense that a dvd error would cause the computer to crash?

The mythtv log file showed no problems. The last entry before the 
computer restarted was about 45 minutes prior to the dvd errors.

The only job at the time of the crash was a k3b rip of the dvd run from 
an ssh connection.

Any ideas on what to do next?

Thanks for any help,

David

> _______________________________________________
> mythtv-users mailing list
> mythtv-users at mythtv.org
> http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users
>