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:
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 be appreciated.
Does this affect only CableTV (QAM), or over-the-air ATSC and/or NTSC as well ?
Log in to reply to this
The changes are specific to ClearQAM, but it would be good to see some testing for OTA ATSC as well to ensure that it didn’t introduce any unexpected regressions. NTSC is completely unaffected (as it uses a different tuner chip and doesn’t have any interaction with the demod).
Recompiled v4l-dvb with your files in place. I’m unable to get usage of the tv currently, but azap is showing a BER/UNC every 20 or seconds with a constant snr 013c.
I did an hg clone of kernel labs v4l-dvb then replaced the existing files with your raw files. After that, I did sudo make install.
Then again, this is the first time I’ve had to compile v4l-dvb, so I’ve probably done something wrong.
Sorry if this doesn’t help!
I’m having some difficulting understanding how exactly you tested the tree. What you need to do is the following:
hg clone http://kernellabs.com/hg/~dheitmueller/hvr-1600-perf-2
sudo make install
And then test.
hg clone http://kernellabs.com/hg/~dheitmueller/hvr-1600-perf-2
sudo make install
Sorry to be a little offtopic, I am considering getting an HVR 1600, but I have heard mixed reviews on them. I am trying to figure out if people that are having problem are because of hardware failures or software issues. A big factor for me is analog quality, so I would like to know how analog performance is. Anyone that can shed any light on this card it would be greatly appreciated.
If I get the card I will definitely test out this driver and any subsequent versions
Any issue someone has nowadays is a *system* level issue:
1. software failing to communicate reliably with the CX23418 due to PCI bus loading/errors or shared interrupt latency,
2. poor signal quality: too weak, overdriven, or external V/UHF noise source.
Issues of Type 1. are not the norm, but frustrating when they occur as there is not much that can be done about it in the cx18 driver. They usually happen on older systems with quirky PCI bus devices or simply aged components and dusty/oxidized card slot connectors, or on somewhat busy single CPU systems.
Issues of Type 2 are well within a user’s control to diagnose and fix. Correcting your cabling plant and adjusting signal levels with external devices can usually clear those up. Devin has also taken a big step for QAM users in attacking the last remaining signal quality bug I know of. Just know that PC tuner cards are small form factor and will never have as good performance as a TV’s or STB’s tuner that can take up a lot more space for components and shielding to manage noise and SNR.
Thanks! That was quite the n00b moment. I followed your directions, compiling and installing the drivers.
The result was a severe degradation in quality of the digital broadcast. The snr did go up from it’s 013e to 0154. However, there is a ber/unc error every other line in azap and the picture is heavily pixealated with audio being delayed.
I did attach a -3.5db splitter, resulting in a snr drop to 014e, but the issue still remains.
Lemme know if any logs, want me to try alternate configurations with the card or even the cabling.
Analog performance is superb. I’m using it to replace the my PCHD-5500’s analog. It has so far not had any problems with recordings or tinny audio, the primary problem my PCHD-5500 has. It’s kinda funny. Both the HVR-1600 and the PCHD-5500 have digital/analog inputs but I use only one part of each card.
If you could please add “debug=1” to the modprobe options for s5h1409, and provide the output of azap and a full dmesg output after doing a tuning attempt, that would be helpful.
You can email them to dheitmueller at kernellabs.com
I think I have nailed down the problem. Please update to the latest version of the tree and try again.
Will do! I’ll ssh in and try it out.
Looks like it worked!
Works perfectly according to azap! No unc/ber errors, constant lock.
Signal is vastly improved, with azap reporting snr 22a4, signal f7xx+, similar to PCHD-5500’s tuner.
I’ll record double check that image/audio reflects it later tonight and schedule a few shows to ensure that it’s working.
For now, I’d say that the issue I was facing is solved.
I’ll continue to comment as I put it through some testing.
Thank you so much!
Argh! Turns out it was the wrong card. My adapters keep changing numbers after a reboot. Not the best testing box.
I upgraded my distro today(up to 9.10) and recompiled the drivers using the advice provider here: http://ubuntuforums.org/showpost.php?p=8226496&postcount=107
My card is now getting a constant 125-127 signal and a ber/unc error every 4-8 lines.
Sorry for this false hope. I’d delete that comment above if I could.
I can provide fresh logs if you want them as well.
Sorry again and thanks for the work your doing.
Could you please add “debug=1” to the s5h1409 modprobe config and email me an updated dmesg after doing a tune with the latest code?
If what you’re saying is true, then I guess the issue you are seeing is a different edge case then the one I just fixed.
thanks, definitely helpful. I have had some people say their pvr 150 does better than the 1600, and others say the 1600 analog is as good as analog gets
Okay, I patched the driver changes into 184.108.40.206, and don’t see any visible or reported difference in ATSC O.T.A. reception on my HVR-1600. My setup has a particularly good test scenario for this: one O.T.A. channel is very much “on the edge” here. I can receive/view it with less than 0.5dB of margin using a Hauppauge HVR-950Q (xc5000), but *not* with the HVR-1600. With or without the patches. Same signal strength and observed quality, just barely on the wrong side of the “digital cliff”.
So, no regression, no improvement for ATSC O.T.A.
Re: analog: I have a PVR-250, which is generally as good or better than most PVR-150 cards, and the HVR-1600 analog gives a noticeably better picture than it.
Earlier, I said “I have a PVR-250, which is generally as good or better than most PVR-150 cards, and the HVR-1600 analog gives a noticeably better picture than it.”
Well, after exhaustive testing this past weekend, I’m not so sure any more. The PVR-250 card I have here, seems to outperform the HVR-1600 in analog mode, pretty much across the band, but partcularly on VHF-low.
That’s my final post on this off-topic bit. 🙂
Personally, I cannot vouch for the performance of the PVR-250, since I have never owned one. If you are seeing problems with the HVR-1600 analog quality though, I would definitely encourage you to start a thread on the linux-media mailing list. You may wish to try to benchmark the relative quality of the s-video inputs of both devices also, since that would help narrow down whether it’s an issue with the onboard video decoder (and mpeg encoder) chip or whether it’s something related to the tuner itself.
No, the analog differences are small, and the 250 is legendary for analog quality — all of that hand-tuned RF stuff in the metal can and all. 🙂 The 1600 does quite well, except for VHF-6, and to a lessor extent VHF-4. No surprise, really, I’m betting the 250 has better FM radio filtering than the 1600 (VHF-6 overlaps FM).
My only complaints about the HVR-1600 are (1) it still has that bug whereby the first analog recording after boot-up is rubbish, so I use dd to read/discard a few hundred KB from the card at boot time. and (2) sometimes Myth-0.21 records video without audio from it, which also happens (more rarely) with the PVR-250 card. Probably a Myth bug, and just about impossible to track down.
I’m another one of those noob’s who did your instructions to test above. All I get in tvtime on Ubuntu 9.10 2.6.31-14-generic is cannot open /dev/video. Gee I guess I shouldn’t have upgraded. I had mythtv working before upgrade.
How do I remove the above and install standard cx18 again? Stupid question I know, sorry.
If I could help I would test, but clearly I am out of my league. I have HVR-1600, regretfully.
One more thing, after I do ‘hg’ and make, I see an error:
/home/bob/hvr-1600/firmware/hvr-1600-perf-2/v4l/firedtv-1394.c:283: error: implicit declaration of function ‘hpsb_unregister_protocol’
make: *** [/home/bob/hvr-1600/firmware/hvr-1600-perf-2/v4l/firedtv-1394.o] Error 1
make: *** [_module_/home/bob/hvr-1600/firmware/hvr-1600-perf-2/v4l] Error 2
make: Leaving directory `/usr/src/linux-headers-2.6.31-14-generic’
make: *** [default] Error 2
make: Leaving directory `/home/bob/hvr-1600/firmware/hvr-1600-perf-2/v4l’
make: *** [all] Error 2
The error above suggests that you never successfully even compiled the code, hence it is not actually installed.
Presumably you are on Ubuntu, which has an issue with their build environment and the firedtv driver. To workaround the issue, open “v4l/.config” and change the line for the “firedtv” driver from “=m” to “=n”. Then you can run make && make install and reboot.
Yes, I just upgraded to Ubuntu 9.10 kernel is currently 2.6.31-14-generic. I will test your stuff again if I know I can undo it and restore default if it don’t work. Is that easy to do?
I have an HVR-1600. I would love to go 100% linux, but to be honest I’ll bet I have spent 30-40 hours trying to get my HVR-1600 to work at all and a single app to use it. Now I upgraded and here I go again. Linux will never go bigtime when it takes such work to get devices working. Does anyone know of a good, up-to-date info link on setting up the HVR-1600, and which app works best on linux? Without it I will tinker for hours and hours.
I just blew system away and started over with a clean fresh install. If I test your mods, can it be undone fairly easy?
Thanks for your devoted work!
If you are unfamiliar/uncomfortable with reinstalling the kernel packages that came with your distribution (with whatever method is appropriate for your particular distro), then perhaps you are not the most appropriate person to be testing this code. The last thing I want is a situation where I feel responsible for hosing somebody else’s machine. Whenever testing alpha-quality kernel code, it always comes with the warning: proceed at your own risk.
I have gotten feedback from a couple of users already, so perhaps the best approach would be for you to hold off until the testing/debugging is complete, and wait for the fixes/improvements to make it into upstream into your binary distribution.
If you want a system where the HVR-1600 works with very little tweaking, then use MythBuntu-9.04 (not 9.10). It should work fine there, after fixing the one little analog startup bug. That bug is fixable by adding this one line to /etc/init.d/mythtv-backend, just after the first existing line of that file:
dd if=/dev/video0 of=/dev/null bs=128K count=1
The digital and analog recording from that card should work very easily with that version of Myth/Mythbuntu. The I/R remote is a totally different story, though.. LIRC is a total bear. 🙂
I got this going on Karmic Koala. I had to set CONFIG_DVB_FIREDTV=n in /usr/src/linux-headers-2.6.31-14-generic/.config to get it to complete the compile. I understand this is a known issue from another thread. This appears to have fixed a persistent audio/video glitch I was experiencing when tuning ClearQAM stations on my cable line. My card reports as Hauppauge model 74041, rev C6B2, serial# 922728. Thanks for the great work!
It seems to improve the QAM reception to the level of my HVR-1250 Samsung tuners with a quick live TV survey. I will record more on my 1600 throughout the week. Good Job Devin.
If you are seeing a difference on the HVR-1250, then I need to look at the code. I intentionally wrote the patch to *not* cause any differences unless it’s an HVR-1600. In the long term, I was planning on trying to enable the changes for other boards and do some testing, but right now there should be absolutely no differences for the 1250 or 1800.
Could you please do an azap against the 1250 both before and after the patches and confirm if there is any difference?
I’m running an HVR-1600 on an ASUS P4P800-E Deluxe mobo with a 3GHz P4, 1GB RAM, and a 1.5TB SATA drive. There is also a PVR-150 in the system, no issues with it.
I’ve been having a tremendous amount of difficulty with QAM channels going momentarily garbled, then recovering, as well as audio periodically dropping out. Audio seems to be out of sync by a mile, well over 500mS anyway. I thought this was a PCI latency issue, but can’t adjust the latency of the SATA interface, so I can’t easily confirm it. It’s stuck at 0mS (dammit).
I tried the new driver, and it appears to have cleared up both the video garbling and audio dropout problems. The sync is still off by over 500mS, but at least I can use the ATSC/QAM tuner now.
There are a number of QAM channels my TV can pick up, but the HVR-1600 can’t. I’m not sure why. This upgrade hasn’t solved that problem unfortunately. When scanning through using myth, the signal strength on these channels shows as 0%, yet when I tune the same channel with the TV’s native tuner, there are several channels present.
On a little closer inspection, I don’t get any channels broadcasting 1080i. I do get 480i, and 720p. This is why some channels are missing.
This is likely some sort of application problem and likely is unrelated to whether it is 1080i, 480i, or 720p. You should perhaps consider running the “scan” tool that comes with dvb-apps, or w_scan, and see if you get results different from what MythTV returned.
Glad to hear the ClearQAM performance is better. The 500ms audio delay issue is almost certainly some sort of application problem. It cannot really be the driver since with digital streams the card just passes through the stream of MPEG packets (it has no understanding of whether packets contain audio or video).
Regarding the signal strength – this is a problem with all cards – there is no well-defined specification for format in which the signal strength is sent from drivers to applications. The problem you are seeing will occur with essentially every ATSC/QAM card supported under Linux.
AZAP? Is that the same as a channel scan using dvb-apps? Can you suggest a place to get that utility for Mythbuntu 9.04? I’ll compare b4 && after patches on ATSC and QAM on my HVR-1250, 1600, and 2250. At the moment I’m recording on different tuners to look through them and see if there is a perceived difference in video artifacts after patches.
Sorry I’m new to this level of testing it may take a while.
azap is bundled with dvb-apps, but unlike scan which looks for channels, azap tunes to a particular channel in your channels.conf and shows you the lock status and SNR.
You shouldn’t need to include the 2250 in your comparison, since that uses a completely different demodulator and tuner (the s5h1411 and tda18271).
Do I need to generate a channels.conf w/ my dvb-apps scan utility? I believe Myth TV puts the channel info in a mysql db instead of a normal text file.
I believe there was a miscommunication the quality of the HVR-1250 hasn’t changed. I was trying to say that b4 the patch my HVR-1250s worked better than my HVR-1600 and now the QAM reception quality has increased so it works as well as my HVR-1250s. Azap shows no change in signal b4 or after the patch on my HVR-1250. Azap shows an increase in signal after the installation of the patch on my HVR-1600. I have recorded and watched about 5 hours of content on 4 different channels and I can confirm that the patch eliminates all previous audio and video artefacts. If you would like to see my azap output let me know were to put it.
Ok, well that’s what I was hoping you would say.
No need to see the azap output – your description seems completely consistent with my expectations.
Thanks for testing. A PULL request went out a couple of days ago, so this should be merged into the mainline v4l-dvb tree soon.
Thank You!! I have been fighting with two HVR-1600 cards in my myth server for about a year. I had constant tearing and digital audio artifacts but now with this updated driver I only get very sporadic audio and video pausing. The pausing is only milliseconds and it is so much better that it has ever been.
3-4 db improvement for me. Thanks!!
Has this been merged into the main codebase yet?
Yes, it was merged into the mainline v4l-dvb tree on November 13th.
Devin, that’s great stuff. I had been trying to get the HVR-1600 to work with hd, and with this, it works near perfect! Thank you so much for your work on this.
the main v4l-dvb was no longer working as the cx18 was not loadable, but there was a fix for that today.
Great, glad to hear you are having success with it.
If this point wasn’t clear, the code was merged upstream, so you should definitely be using the mainline v4l-dvb tree and not any hg tree in the KernelLabs repository (those trees are just there for the original customer).
Glad I found this post, my HVR-1600 HD now works without glitchy video&audio. Thanks.
I think the HVR-1600 is broken again for QAM. it’s not working here and I’ve tried everything I can think of.
Was it working at some other point? If so, can you try to install that version of the driver and see if it works? That would help narrow down when the breakage was introduced (if there actually is a regression in the driver).
What applications did you test with? Have you tried the same tuner and cabling under Windows to see if you are actually able to receive ClearQAM channels at all?
Have you tried hooking up a regular television that supports ClearQAM and see how many channels you can get?
Great article. Very big help especially for those of us in the digital signage industry. Would help to improve the quality of our saas product by giving high quality as well as high service.
You must be logged in to post a comment.