[mythtv-users] Best tuner? - now driver question
mythtv at guiplot.com
Tue Jan 12 16:53:16 UTC 2021
On 12/6/20 11:34 AM, DaveD wrote:
> On 12/6/20 6:45 AM, Barry Martin wrote:
>> Over a year ago created a new BackEnd using a Hauppauge 1609: quad
>> tuner. The old system used their 1600 and 2250. Antenna untouched;
>> the new tuner took care of 99% of my previous pixellation and dropout
>> Antenna positioning, coax quality, and other hardware factors are
>> also important, but the newer generation of tuners are better at
>> compensating for signal strength variations due to wind. FWIW I
>> actually have two antenna systems here: both antennae are essentially
>> identical (same model, purchased maybe six months apart). One goes
>> to the Backend. the other to the TVs. Whole bunch of variables due
>> to the distribution but some TVs are better able to display when it's
>> windy, some are not. The older and cheaper TVs will break up while
>> the newer and better TVs will have an essentially solid display. And
>> there have been times we've switched from OTA TV to Live TV via
>> MythTV because of the poor signal.
>> So yes, the tuner makes as much difference as the antenna does.
> The 1609 sounds perfect. I googled it and Amazon has 3 sellers from
> $230 to $250, and the $230 is back-ordered, due in-stock Dec 15. So I
> checked Hauppauge's site, and their store has if for $120. This is
> odd. Anyway, I ordered one as well as one of their dual USB sticks.
> Hope this eliminates those dropouts. Thanks for the info.
> Dave D.
I've been studying the performance of my new Hauppauge Quad vs the
performance of my Old Dvico Fusion dual. I wrote a GUI app using QT (my
self-tutorial) that has a bar graph for signal strength and another for
SNR. They update every 100mS and it works great for watching signal
strength while moving antennas. It's based on code from dvb-apps and
uses channels.conf files generated with scandvb. When invoked, it loads
the channels from the .conf file and I can choose which channel I want
to monitor. I can open as many instances as I want and monitor as many
channels as I want (up to the number of adapters, which is now 6).
Monitoring multiple channels simultaneously while moving the antenna
With a -s command line argument, my app will successively monitor each
of the channels in the file for 10 seconds and log the results,
including the card used for tuning. With other command line arguments,
I can specify which card to use and which .conf file to use. Using cron
jobs, I've been logging signal strength and SNR statistics hourly for
each of the cards for about 4 days.
Info was interesting: some times on some channels the Dvico did better,
other times/channels the Hauppauge did better. Overall, though, they
are very similar. One of the parameters logged is how many of the
samples have a lock. 100% lock for the full monitor time (also
configurable) indicates a reliable recording. Anything less relates to
varying degrees of pixelation. My signals are mostly good, but some are
very weather-dependent. When a low moves through with associated south
wind, forget KOMO!
After a couple of days, I stopped checking the data and let it run for a
week before looking again. Unfortunately, after about 3 days the logged
card started to always be "unknown". That's the default. When the
program starts, it checks for adapters by listing /dev/dvb. It then
finds the chip for each adapter using "dmesg | grep 'DVB: registering
adapter '" which lets me build a unique name for each card. The problem
occurred when dmesg got overloaded with messages and the old ones were
dropped. No more output from the dmesg | grep command.
Whenever I've used dmesg in the past, it showed history all the way back
to the boot. I never even realized there was a limit, but now the
driver for the Hauppauge spams dmesg every time it changes channels with
"xc5000: Firmware dvb-fe-xc5000-1.6.114.fw loaded and running"
(ridiculous!). With my app changing channels 12 times every hour (plus
normal use), it takes about 4 days to fill the dmesg ring buffer. The
Dvico does a similar output to dmesg, but only once per app invocation.
Are there any experts on drivers on this list? Is there a way I can
silence these (somewhat) useless log entries? I started to look into
changing the source for the driver, but that got overwhelming pretty
quick. I know, now, that relying on dmesg will always, eventually
break, but normally I end up rebooting every couple of weeks or so for
other reasons. I'd like to keep my logging working for more than a few
days, and I can always just record the card ID with something that runs
on boot, but it just bothers me that something spams my system logs this
way. Suggestions appreciated.
More information about the mythtv-users