[mythtv-users] Backend crash. Do I have too few hard drives?
lists at glidos.net
Mon Dec 6 12:50:05 UTC 2010
On 06/12/2010 12:35, Andre wrote:
> On 6 Dec 2010, at 11:21, Paul Gardiner wrote:
>> On 06/12/2010 10:32, Andre wrote:
>>> On 6 Dec 2010, at 10:15, Paul Gardiner wrote:
>>>> On 05/12/2010 17:38, Andre wrote:
>>>>> On 5 Dec 2010, at 16:49, Paul Gardiner wrote:
>>>>>> On 04/12/2010 12:52, Andre wrote:
>>>>>>> 1) look at pci latency for the HD-S2 card
>>>>>> So presumably you currently have a working HD-S2
>>>>> I do, also a HVR-4000 which is a HD-S2 with some extra bits.
>>>>>> card. What firmware are you using? And which driver
>>>>> fw 18.104.22.168
>>>> Ah right. Same here.
>>>>> Driver was the v4l latest on 2010-09-03 revision 15139 if I'm reading the right thing from hg view!
>>>>> Should be fine with a current v4l though, probably in kernel drivers are fine too but they certainly were not in Ubuntu 9.10 so I wasn't taking any chances.
>>>> modinfo cx24116 tells me:
>>> Ah, didn't think to try that for a version, doh!
>>>> filename: /lib/modules/22.214.171.124-0.5-desktop/kernel/drivers/media/dvb/frontends/cx24116.ko
>>>> license: GPL
>>>> author: Steven Toth
>>>> description: DVB Frontend module for Conexant cx24116/cx24118 hardware
>>>> srcversion: 08166A1122785592C226036
>>> Exactly the same srcversion.
>>>> vermagic: 126.96.36.199-0.5-desktop SMP preempt mod_unload modversions 686
>>> This is different but I expect that's because yours is built for a newer kernel.
>>>> parm: toneburst:DiSEqC toneburst 0=OFF, 1=TONE CACHE, 2=MESSAGE CACHE (default:1) (int)
>>>> parm: esno_snr:int
>>>> parm: debug:Activates frontend debugging (default:0) (int)
>>>> Not sure what that tells me. Maybe I should build the latest from the
>>>> hg repository. linuxtv site mentions the driver being broken in
>>>> kernel 2.6.30, 2.6.31 and 2.6.32.
>>> I'm running 2.6.32 and can vouch for that, it works but not reliably no DVBT for the HVR-4000 and not at all with the latest firmware. There was some discussion on here about it and I ended up doing some testing which I think was for Ubuntu 10.10 alpha.
>> So the fact that mine does work most of the time, the failures I
>> do see don't require any resetting of the device and don't
>> involve log messages about the device, plus my having the
>> same srcversion as you, all point to that not being the
>> cause of my problem I'd guess. Although I have still
>> to try uping the latency from 32 to 64.
> You said that lspci showed latency to be 0, this looks like an issue I've seen with some bios that don't set this properly, see lkml for details. PCIe always shows as 0 but there seems to be a different mechanism used for this.
There were 4 entries for the Nova-S2 HD. They were all 32 latency. The
ones showing 0 were SATA controllers and USB controllers. I'm guessing
I shouldn't mess with SATA and USB latency?
> Some dvb drivers set the PCI latency when they load up, some exit with errors if it's not enough. cx24116 seems to go on regardless, maybe because it doesn't matter but I know if I set mine back to 32 I get glitches in recordings and the odd failed recording again. Whether this is purely the HD-S2 or interaction with other hardware I don't know.
I don't seem to have glitches or failed recordings, other than if
mythbackend crashes or gets stuck in an unresponsive state, but
I guess that could still be down to the Nove-S2 HD. I think it
might be a problem starting a new recording. I've yet to see problems
other than when a new recording is starting up.
>>> So is the new (different) HDD making any difference?
>> Too early to say. No problems yet. It is exactly the same
>> model drive, so the only difference is I have it as a
>> single partition, rather than 2. I must remember in
>> the future to use a range of makes when I buy HDDs, so
>> that when problems occur I can use swapping as a way to
>> track the problem down.
> Well if you were having a similar problem to my HD103 drives you would have seen some signs when copying lots of files to the new partition.
No signs of that sort of problem at all. No corrupted files. No errors
> the only other thing I can add is I notice that if something else is accessing a recording drive at all heavily during a recording then myth will "give up" part way through a recording or never start (0B recording). Moving recordings between disks, even when ioniced (no, I'm not moving the in-progress recording) or xfs_fsr running are the usual causes of this, I guess this is the root of the OS& DB on a different drive advice.
But did that cause mythbackend to crash or become unresponsive?
> I used to use a USB attached HDD for nightly backups, took a while to spot the correlation between a large change needing a long running backup and a co-timed recording that failed. I wasn't even backing up any recording drives but changing to a firewire disk and more recently a hot plug sata disk has stopped this problem.
> It is almost as if myth uses some special extra fragile way to access the disk or just doesn't like to share it's toys :-P
> Sorry if this stuff seems random but I have three myth systems myself and another half dozen friends I've set up systems for or with and these are common problems most of us see, maybe I'm doing something wrong on all of them!
> One final thought and then I'm out;
> The problem is DVBS specific and the recent UK weather is not very conducive to satellite reception, also PC DVBS cards usually need more signal than all but the worst set top boxes. Are you sure you are getting a good clean signal? Myth will fail mid recording or not start if there is too much corruption in the received signal.
I don't think it's that. I've yet to see glitches in recordings.
Actually the successful recordings (which is almost all), look
More information about the mythtv-users