hvr-1600 fails frequently on multiple recordings

I have a fairly new HVR-1600 which I have seen fail quite a number of times now when it's asked to record more than one channel on a clearqam multiplex. This time it was 3 recordings at once.

There's nothing at all in the kernel ring buffer, just mythtv reports a failed recording. Usually one of the files being recorded to will only be 376 bytes long and the rest will be 0 bytes.

I am running ubuntu's 3.2.0-27-generic kernel with what looks like a 1.5.1 cx18 driver. The card is either a:

14f1:5b7a Conexant Systems, Inc. CX23418 Single-Chip MPEG-2 Encoder with Integrated Analog Video/Broadcast Audio Decoder

or a:

4444:0016 Internext Compression Inc iTVC16 (CX23416) Video Decoder (rev 01)

Sorry. I don't recall which is which any more.

But I really need to figure this out since failed recordings is causing all kinds of disappointment around here. I'm really at the end of my rope with it.

Tomorrow morning I am going to demote this card to secondary duty and promote my HVR-950Q to primary duty since I never had this kind of grief with it. But even in secondary duty, it could very well be called upon to record multiple clearqam channels simultaneously so I would really like to get this figured out.

Any ideas?

Cheers,
b.

I think the real question at this point is: what version of MythTV are you running? I've seen so many reports recently of breakage in the MythTV codebase related to recording, I am almost inclined to demand you reproduce it outside of MythTV before we even spend any time talking about it.

Also, has anything changed in your environment? Was it working before, and then you upgraded the kernel or Myth, and now it's not working? Or has there been a consistent pattern of failure over some extended period of time?

The cx18 driver has changed very little as of late - the MythTV codebase has changed heavily and people are all over the place complaining about breakage.

I'm not trying to get into the finger-pointing game, but I just want to better understand the history/background before I can make any recommendations.

Devin

Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com

0.25-fixes, specifically 46cab93 from 20120801. Indeed, not the latest, but I don't think much if anything has been done in the affected code paths. I want to upgrade and even thought about doing it today but today I also moved the HVR-1600 into secondary duty (and promoted the HVR-950Q) and didn't want to make another change which would only confuse the original cause.

I understand that making such a change is not ideal in terms of debugging, but the grief of having a whole night of television recordings fail just causes too much strife here. And most nights it wouldn't really matter but of course it has to happen on the one night of the week that people here have to watch a show the same night it's broadcast or else hear about all of the spoilers at work the next day. :-(

That's fair enough I suppose. The one problem is that this problem is very intermittent. It only happens about once a week or so, not really at the same time every week though so not nearly repeatable.

Is there much more to recording from these devices though than:

# [ tune channel ]

# cat < $device > $file

akin to recording from PVR-x50s? I guess what I'm driving at is how much/little code are we talking about in Mythtv to do this?

Nothing other than the HVR-1600 being somewhat new. It has not really been worked hard since I got it given that I got it in the "low season".
Now that fall is here there is lots more on television and the card is
being asked to perform multiplexed recordings way more frequently.

Yes, but has always been on "light duty" since I got it.

Nope. No upgrades correlating.

Well, it's happened now 2-3 times since the start of the fall season, which means when it's being asked to do more.

Which does seem like a fair correlation. The only other possibility I am considering is a defective card since it's never really proven itself yet.

No, I completely understand your perspective and these are all very fair questions. I hope you will allow me to be devil's advocate in hopes of getting to the bottom of it. :-)

Indeed. Always a good idea. There's a reason doctors take patient histories before diagnosing. :-)

FWIW, I'd be happy to take this over to the mythtv list if you want to pursue it being a mythtv problem. I filed a bug about mythtv's inability to recover from this situation and it deadlocking until killed (a KILL signal is typically required, demonstrating how badly mythtv is handling this situation) when this happens and even posted to the list about the bug but got zero response.

Cheers,
b.