[mythtv-users] Best tuner? - now driver question

[DaveD]

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 
>> issues.
>>
>> 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.
>>
>> Barry
>
> 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 
works GREAT.

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.

Dave D.