It’s been a while since we’ve had a blog post, so I figured it would be a good time for an update as to some things going on. We’re continuing to work in a number of areas, although in some cases things are moving along “behind the scenes” and are less visible to the public.
First, let’s talk about the HVR-950q….
As a result of some consulting we did in the last month, I spent *alot* of time digging into the tuning behavior for the HVR-950q. This included finding several bugs which explain some of the “sometimes tuning just fails” type behavior. These are the sorts of things that only happen 1% of the time, so they tend to be quite annoying to track down. I’ve said this in the past and it continues to be true – getting a device up and running is very different than making it work reliably. It can take a ton of work to get a product from a state where it’s good enough for casual TV watching to a state where it’s good enough for embedding in a commercial product.
The patches will be posted soon enough, and I believe that everybody will be happy to see faster tuning times and more reliable/consistent behavior in particular for digital tuning (ATSC/ClearQAM). But to make the analog people happy as well, I also isolated a nasty bug where sometimes changing channels would cause a green screen and it would stay that way until you restarted the device.
All that said, there are still a couple of lingering issues that I want to investigate deeper — in particular one issue related to analog audio not always working. It just goes to show that even if you spend weeks working on a single driver that there are always some weird edge cases outstanding that still need to be isolated and worked on…
Moving on to tvtime…
Kernel Labs’ involvement with tvtime falls under the adage “necessity is the mother of invention.” We needed a tool that was readily available which demonstrated to customers that our drivers were working as advertised. This, combined with the fact that tvtime didn’t build against recent Linux distributions, prompted us to set up our own repository and start making fixes as well as incorporating patches from the various distros. We became a “defacto maintainer” in light of nobody else really being willing to do the work.
Times have changed though and in recent weeks there has been renewed interest in forming a development community around tvtime. This is largely been among the LinuxTV developers, as well as a couple of individuals who have been porting patches between various distros. The net result though is that the tvtime tree will be moving to linuxtv.org, where it can be maintained on an ongoing basis by several people (myself included). This will hopefully lead to the remaining patches from distros being consolidated and the distributions all switching to the LinuxTV version of tvtime as the “official upstream provider”. Plus, with multiple maintainers there should be less of a situation where perfectly good patches get blocked from being merged as a result of a single person being too busy (something which I myself have been known to cause).
In closing…
Beyond that, we’re continuing to grind away at drivers for new devices, do fixes in userland as needed (in fact, some VLC fixes I did for closed captioning were merged upstream last week), and we’ll continue to provide status updates as things can be made public…
Devin,
I have a mythtv setup with a couple of wintv-hvr 850 tuners. Every now and then, a recording randomly doesn’t record. I’m hoping that the problem may be resolved with some of the changes you’ve been working on.
But it’s not clear to me how to test your various updates. Is there a local repository I should grab from?
Hello tripperda64,
First off, the patches in question only apply if you have the au0828/au8522 based version of the HVR-850 (there have been three different hardware designs with that name). Also, it largely depends on whether your problem is with ATSC/QAM or analog. To answer your question though, haven’t had a chance to cleanup and post the patches yet. Hoping to do so next week.
Cheers,
Devin
Hi Devin,
I’ve been offline for a while, but that appears to be the tuner that I have:
[ 16.598997] tveeprom 2-0050: Hauppauge model 72001, rev B3F0, serial# 6911144
[ 16.599001] tveeprom 2-0050: MAC address is 00:0d:fe:69:74:a8
[ 16.599004] tveeprom 2-0050: tuner model is Xceive XC5000 (idx 150, type 76)
[ 16.599006] tveeprom 2-0050: TV standards NTSC(M) ATSC/DVB Digital (eeprom 0x88)
[ 16.599009] tveeprom 2-0050: audio processor is AU8522 (idx 44)
[ 16.599011] tveeprom 2-0050: decoder processor is AU8522 (idx 42)
[ 16.599013] tveeprom 2-0050: has no radio, has IR receiver, has no IR transmitter
Have those fixes been posted upstream, or is there a way to pick up those fixes and try them out? thanks in advance.
Hello tripperda74,
I’m sorry to say that I’ve been really busy with a couple of other projects and haven’t had a chance to get these patches put together. I definitely haven’t forgotten about them though.
Devin
Thanks for continuing to work on this! I’ll be glad to test when you post the patches. I’d also like to encourage you to look at the analog lockup issues with usb IRQ and sound as the 950Q is only partly useful if only the ATSC/QAM portion works properly.
Devin,
I have a 950q with AU8522 with mythtv. I am experiencing some of the issues you described. Inconsistent tuning issues with ATSC (sometimes it just wont tune) and sometimes when I reboot, the tuner does not work at all. Have you clean up and post the patch? Where might I find it? I understand that this is basically volunteer work for you so I am not pressuring, just would love to know where I can find the patch if/when it is done.
Thanks,
Andrew
Devin,
I’m having an issue with my 950Q, not sure if it is one of the issues you are fixing or not. When I view channels with mplayer, it sometimes works and sometimes doesn’t. When it doesn’t work, I usually see AC3 audio errors and the video plays very slow or is blocky. I look forward to testing your patch.
Thanks,
Derek
Hello Derek,
That sounds more like a signal quality issue. Have you looked at the SNR and error counts using a tool such as azap for femon?
Devin
Hi Devin,
Thanks for the quick reply! I did look at azap and after the initial FE_LOCK, I noticed that the ber and unc values showed a value but then remained all zeroes. I did notice that the signal and SNR columns would change to zeroes occasionally. I hooked a regular TV up to this jack and it is able to play video fine. I also have a HD HomeRun that I hooked up and I noticed that the signal level changed between 89-90% in the HD HomeRun application. I also ran azap with the HDHR and noticed that the signal and SNR values did not change to zeroes like the 950Q. Video playback appears to be fine when I use the HD HomeRun. I tried moving the computer to the location where our cable comes in and the values remained the same.
Here is the azap output from the 950Q:
root@slackware:~# azap -c channels.conf WGAL-DT
using ‘/dev/dvb/adapter0/frontend0’ and ‘/dev/dvb/adapter0/demux0’
tuning to 423000000 Hz
video pid 0x0880, audio pid 0x0881
status 00 | signal 0000 | snr 0000 | ber 00000000 | unc 00000000 |
status 1f | signal 0190 | snr 0190 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal 0190 | snr 0000 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal 0000 | snr 0000 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal 0190 | snr 0000 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal 0190 | snr 0000 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal 0190 | snr 0000 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal 0000 | snr 0190 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal 0190 | snr 0190 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal 0190 | snr 0190 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal 0000 | snr 0190 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal 0190 | snr 0190 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal 0190 | snr 0190 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal 0000 | snr 0000 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
^C
root@slackware:~# azap -c channels.conf WHPDT
using ‘/dev/dvb/adapter0/frontend0’ and ‘/dev/dvb/adapter0/demux0’
tuning to 681000000 Hz
video pid 0x0840, audio pid 0x0841
status 00 | signal 0118 | snr 0118 | ber 00000000 | unc 00000000 |
status 1f | signal 0000 | snr 0000 | ber 000000aa | unc 000000aa | FE_HAS_LOCK
status 1f | signal 0190 | snr 0190 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal 0190 | snr 0190 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal 0000 | snr 0190 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal 0000 | snr 0000 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal 0190 | snr 0000 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal 0000 | snr 0000 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
^C
root@slackware:~# azap -c channels.conf WLYHDT
using ‘/dev/dvb/adapter0/frontend0’ and ‘/dev/dvb/adapter0/demux0’
tuning to 759000000 Hz
video pid 0x0800, audio pid 0x0801
status 00 | signal 0000 | snr 0000 | ber 00000000 | unc 00000000 |
status 1f | signal 0000 | snr 0190 | ber 00000074 | unc 00000074 | FE_HAS_LOCK
status 1f | signal 0000 | snr 0000 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal 0000 | snr 0190 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal 0190 | snr 0190 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal 0000 | snr 0190 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal 0000 | snr 0190 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal 0000 | snr 0000 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal 0190 | snr 0000 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal 0190 | snr 0000 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal 0000 | snr 0190 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal 0000 | snr 0190 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal 0000 | snr 0190 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
Thanks,
Derek
The SNR going between 0x190 and 0x000 is actually a red-herring. It’s a bug I found myself a couple of months ago and have a fix for (in the patch series I’m preparing to submit upstream). You’re *not* actually losing signal lock but rather you’re the uppermost limit of 40.0 dB (meaning you have a very strong signal), and a bug in the logic results in it saying “0” instead of “40.0”.
Hi Devin,
Do you think that bug may be affecting our mplayer playback, or does it just affect the SNR output in azap?
Thanks,
Derek
The bug in question has nothing to do with the *actual* signal quality. It’s just a bug in the presentation of the SNR.
Devin
Thanks Devin. I’m pretty close now. I tweaked some of the mplayer parameters, including things such as -mc 2, -tsprobe, and -cache. Now everything seems to sync up properly.
Thanks,
Derek
I’m currently seeing similar behaviour with my 950Q and Mythtv. It seems about 50% of the time I schedule a recording, it fails. After that I am unable to get live tv or a capture from the card until reboot. I’m tuning off OTA, with fairly low signal levels.
Tested some more, it will record for a while, then end up recording to 0byte files, live tv says TL__ partial lock. If I stop the backend, azap can get a lock. Restarting backend, the tuner still won’t lock on.