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

[Stephen Worthington]

On Tue, 12 Jan 2021 08:53:16 -0800, you wrote:

>I've been studying the performance of my new Hauppauge Quad vs the 
>performance of my Old Dvico Fusion dual.

Bare in mind that the signal strength and s/n ratio values reported by
different cards (even from the same manufacturer) can not be compared,
as they will report different values for the same multiplex.  These
values are uncalibrated.

>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.

What distro are you using?  If it is Ubuntu, then you should find all
the dmesg logging also in the /var/log/kern.log.* files.  These are
rotated by the system in accordance with the settings in the
/etc/logrotate.d/rsyslog file.  If you want to keep more in each
kern.log* file, and keep the older logs uncompressed, then you can
make a different entry there for kern.log with customised settings.