As a result of numerous users reporting that their HVR-1800 didn’t work in analog mode, I finally got some time tonight to dig into the situation.
If you don’t care about the details, the short answer is I’m working on it and be patient. If you want to get some insight into the gory debugging process, keep reading…
Over the next few blog posts, I’ll be walking through the typical debugging process. I don’t actually know what the actual problem(s) are at this point, so this is a chance for those of you at home to play along. Here’s what we do know:
Users have reported a variety of different problems with the HVR-1800 board. Some of these problems appear to have been present since the original cx23885 driver was written; others appear to be a recent regression as a result of work done to add support for the HVR-1850. We’ll be breaking down the individual problems, understanding which problems are inter-related, and get into some of the details regarding the differences between the 1800 and 1850.
We’ve got reports of problems with raw video, different problems when using the onboard MPEG2 encoder, and yet more problems related to audio. Some of the problems always occur regardless of the input chosen, and others only occur when using the onboard analog tuner. In other words: a target rich environment.
As a start, I bootstrapped the latest kernel, and reproduced some different scenarios using the basic tools (i.e. v4l2-ctl, v4l2-dbg, cat, etc). While some of the original reports were from MythTV users, it’s useful to eliminate Myth from the equation if possible. This makes testing considerable simpler and reduces the amount of time wondering if it’s a MythTV bug. While there have been cases where problems *only* manifested themselves with MythTV, in this case the bugs seem readily reproducible even without it.
And in the interest of full disclosure: I’ve been known to cheat at games like this. While I’ll be both showing and using the tools/techniques which are typical to debug this sort of problem, I’ve got an intimate understanding of the hardware design as well as access to the datasheets for the various chips under NDA. Nonetheless, while I may take a shortcut here and there and peek at the datasheet at times since I don’t have a month to figure this out, the underlying debugging methodology is still sound (it just takes longer).
It’s probably also worth recognizing user “tekdoc”, who actually did some git bisects and observed some suspicious behavior by applying/reverting certain patches. He’s definitely done a good bit of legwork which will serve as a good starting point in nailing down these issues.
At this point, I’ve got a machine with a 1800 board in it, built the current 3.4.0-rc7 tree, reproduced a couple of the steps provided by Britney Fransen (a very help user), and poked around at the registers a bit. In the next blog post, we’ll quantify the actual problems so they can be broken down and analyzed individually.
Anyway, this should be fun. 
Please let me know. I want to know if it’s worth it to move forward with this. Are there any users or companies that want or need to use ATSC-MH in Linux, or should I just wait until I have nothing better to do? I *will* get this completed eventually, I’m just trying to understand how much it will benefit the community. If nobody cares, then I’ll surely get this all done within the year (or so) … but if people really are interested, I can have it ready by next weekend. You tell me.