Archives | October 2009

If you are an HVR-1600 user who has noticed the ClearQAM tuning performance under Linux was worse than under Windows, this should make you happy. As a result of the work described in the previous post, there is now a tree that contains the various fixes: http://www.kernellabs.com/hg/~dheitmueller/hvr-1600-perf-2 The goal is to submit this upstream, but before that we want to get some people to try it out first and submit feedback on their experience. Thanks go out to ONELAN Limited for sponsoring this work! Feedback (good or bad) on the blog or the linux-media mailing list would...

---

Haven't had much time to update the blog lately. All week I've been quietly grinding away at two basic issues: PAL VBI support for the em28xx chip, and identifying/addressing the HVR-1600 performance problem. I often get questions from users along the lines of "how do you make boards work?". Reverse engineering is a bit of a black art, but I figured I would offer some insight as to how the process works. If you don't actually care how tuners are designed and how we figure out how to make them work, stop reading now. If this stuff interests you, read on, and feel free to put something in the comments...

---

I started working on the media controller stuff again, and was unfortunately sidetracked when I realized that any attempt to stream audio against my HVR-950 would cause the kernel to panic. Spent most of the evening chasing down the bug in the isoc handling code which would cause a page fault. Issued a PULL request for it tonight: http://kernellabs.com/hg/~dheitmueller/em28xx-audio-panic So if you happen to have an em28xx device and have been hitting kernel panics whenever you tried to listen to the audio, this should fix that issue. On a separate note, I issued a PULL request last night...

---

Did some more testing of the HVR-950q under MythTV. Wrote some patches to get rid of a couple of spurious error messages. However, in the end the code currently in the v4l-dvb codebase today does work with MythTV, as long as you have the latest snapshot of 0.22, use the no_poweroff xc5000 modprobe option, and make sure that the capture profile is set to 720x480. It's worth noting that Ubuntu Karmic has already picked up the changes, so if you are tracking the bleeding edge Karmic release then you have the fix. There's still the problem with the audio squelch during channel changes. I spent some...

---

After three nights of debugging various issues, I now have the analog side of the HVR-950Q working properly with MythTV. Special thanks go out to Janne Grunau for promptly merging my patch providing UYVY support to MythTV: http://svn.mythtv.org/trac/changeset/22343/trunk I will be setting up a tree this weekend with the 950q fixes. In the end, we had a power management bug in the au8522, the MythTV issue described above, and the saturation/hue controls not being implemented causing spurious errors in the mythbackend log. There is also a popping in the audio that occurs when changing...

---

Spent tonight continuing to debug the 950q under MythTV. I temporarily disabled the au8522's power management, and the MythTV channel scanner started to see the channels, but it was otherwise behaving quite erratically. MythTV seemed to be trying to do a scan of both the ATSC side and the analog side at the same time, even though both were in the same device group. Also, the "scan for channels" button was disabled in analog mode, which I couldn't understand why. I assumed my device was announcing its capabilities improperly to MythTV, until I realized that the same behavior was occuring with the older...

---

So I am now at the point where I am ready to start debugging signal lock. This is the phase in the project where all the code is written but has never actually been tested/debugged. My situation however is complicated by the fact that I do not actually have access to a DVB-T signal currently. While I will be soliciting testers in general once I have something that I think basically works, at this point, I need one experienced user with access to a DVB signal who can provide an environment for me to remotely debug the board. The ideal candidate: Owns a PCTV 340e Has used DVB devices...

---

Yeah, life can throw you a curve ball once in a while. My older HP Desktop is a 2.4GHz HT 1GB system. It's 5 years old. Great value for money. It's also my MythTV backend... and it's also been slowly dying for the last 3 months. What a saga. With the TV schedules just restarting here in the US could it have come at a worse time? What happened? It started with dead memory a year ago, followed by a blown out power supply 4(?) weeks ago, replaced. On reboot my PCI DViCO based tuner doesn't initialize properly so I have to physically pull the PCI card for 30 seconds, meaning it's difficult to manage...

---

Now that I finally got a MythTV system setup again, I spent the evening doing some testing of the HVR-950q analog support. I was able to reproduce both issues that others reported, and have started to debug the problems. It seems like the big problem is that MythTV does a different sequence of V4L ioctls than tvtime, which in at least one case causes problems with power management on the au8522 decoder. Right now I'm focusing on the channel scanning case, where I can see pretty clearly that MythTV does the tuning attempt but never enables streaming. We currently rely on the V4L2 STREAM_ON...

---

This weekend I spent some cycles working on the xc4000 driver and the surrounding code required for the PCTV 340e. I think I now have the PLL properly programmed, and I worked around the i2c clock stretching deficiencies in the dib0700. We're quickly approaching the point where I'm ready to start testing for signal lock. Once we have signal lock, there will be a call for testers, so stay tuned!

---