Bug #3927
Losing SNR display on DVB-T/S adapters in 4.1 (was working in 4.0.9)
100%
Description
When starting up Tvheadend, initial SNR display for DVB-T/S adapters looks correct (dB values, see first screenshot), then it gradually fails on each input (shows as 0% SNR) and will finally never return to normal.
The attached screenshots were created during Tvheadend startup, showing in this order:
- normal SNR display (values in dB)
- SNR display on 2 inputs changing to 0%
- SNR display on 3 inputs changing to 0%
- SNR display on 1 input returning to normal (dB)
- SNR display on 2 inputs lost permanently during error-free viewing
All inputs were configured with 'Force old status' disabled.
This installation is running on Ubuntu Xenial and was just upgraded from version 4.0.9-4~gac9e47d~wily to version 4.1-2150~gfd72688~xenial. With version 4.0.9 the switch to 0% SNR could be observed in times of complete signal loss, but it always returned to normal dB values when the signal recovered. In version 4.1, the loss of proper SNR display seems to be permanent.
Files
History
Updated by Mark Clarkstone about 8 years ago
Enable Force old status - Always use the old ioctls to read the linuxdvb status (signal strength, SNR, error counters). Some drivers are not mature enough to provide the correct values using the new v5 linuxdvb API.
You can find it under the frontend params.
Updated by Oliver O about 8 years ago
Mark Clarkstone wrote:
Enable Force old status - Always use the old ioctls to read the linuxdvb status (signal strength, SNR, error counters).
Have tried this. Results are even worse. Only one input provides a reasonable SNR value, the others seem to fail right from the start (see screenshot attached).
Some drivers are not mature enough to provide the correct values using the new v5 linuxdvb API.
Yes, I've read about this before. Does not seem to apply here, since everything worked with TVH 4.0.9 using the same drivers.
Updated by Jaroslav Kysela about 8 years ago
Provide '--trace linuxdvb' . https://tvheadend.org/projects/tvheadend/wiki/Traces
Updated by Oliver O about 8 years ago
- File tvheadend.log tvheadend.log added
- File Screenshot from 2016-08-12 12-51-31.png Screenshot from 2016-08-12 12-51-31.png added
- File Screenshot from 2016-08-12 12-51-38.png Screenshot from 2016-08-12 12-51-38.png added
- File Screenshot from 2016-08-12 12-51-48.png Screenshot from 2016-08-12 12-51-48.png added
- File Screenshot from 2016-08-12 12-51-58.png Screenshot from 2016-08-12 12-51-58.png added
- File Screenshot from 2016-08-12 12-52-18.png Screenshot from 2016-08-12 12-52-18.png added
- File Screenshot from 2016-08-12 12-54-45.png Screenshot from 2016-08-12 12-54-45.png added
- File Screenshot from 2016-08-12 13-18-41.png Screenshot from 2016-08-12 13-18-41.png added
Here is the requested trace along with some screenshots to show the status display.
Devices used as identified in the system journal:
adapter 0 (DVB-T #0): Afatech AF9033
adapter 1 (DVB-T #1): DiBcom 7000PC - Hauppauge Nova-TD Stick (52009) [tuner #1 (dual tuner stick)]
adapter 2 (DVB-T #2): DiBcom 7000PC - Hauppauge Nova-TD Stick (52009) [tuner #2 (dual tuner stick)]
adapter 3 (DVB-S #0): Montage Technology M88DS3103 - TechnoTrend TT-connect S2-4600
I've started Tvheadend in its normal configuration, let it scan all DVB-T and DVB-S muxes for EPG data, then selected some channels for live watching (up to 2 simultaneously). Interestingly, the last screenshot shows that I had lost SNR display on only one of the two DiBcom 7000PC DVB-T inputs sitting on the same dual tuner stick (with error-free live video on both).
Hope this helps. If you'd like a trace from a reduced configuration, please let me know.
Updated by Oliver O about 8 years ago
Here is further analysis and a suggested fix:
The attached C program gathers current SNR readings using the old and new DVB APIs. When invoked during a TVH epggrab run, it looks like this:
# ~/Test/DVB/snr /dev/dvb/adapter3/frontend0
18:08:09 SNR: new=12.041 dB, old=120 18:08:10 SNR: new=12.041 dB, old=120 18:08:11 SNR: new=12.041 dB, old=120 18:08:12 SNR: new=12.041 dB, old=120 18:08:13 SNR: new=N/A, old=0 18:08:14 SNR: new=13.222 dB, old=132 18:08:15 SNR: new=12.787 dB, old=127 18:08:16 SNR: new=13.222 dB, old=132 18:08:17 SNR: new=13.010 dB, old=130 18:08:18 SNR: new=13.424 dB, old=134 18:08:19 SNR: new=13.222 dB, old=132 18:08:20 SNR: new=13.617 dB, old=136 18:08:21 SNR: new=13.010 dB, old=130 18:08:22 SNR: new=13.010 dB, old=130 18:08:23 SNR: new=13.617 dB, old=136 18:08:24 SNR: new=13.222 dB, old=132 18:08:25 SNR: new=13.617 dB, old=136 18:08:26 SNR: new=N/A, old=0 18:08:27 SNR: new=12.787 dB, old=127 18:08:28 SNR: new=12.552 dB, old=125 18:08:29 SNR: new=12.552 dB, old=125 18:08:30 SNR: new=12.787 dB, old=127 18:08:31 SNR: new=12.787 dB, old=127
Conclusions:
- The new API call sometimes returns an intermediate result of
FE_SCALE_NOT_AVAILABLE
(presumably if the tuner is not ready yet). According to https://linuxtv.org/downloads/v4l-dvb-apis/frontend-properties.html#DTV-STAT-CNR, this is proper behavior. - For the Hauppauge Nova-TD and TechnoTrend TT-connect S2-4600 inputs, the old API call apparently returns a decibel value multiplied by 10 (which does not conform to the API spec and thus constitutes a bug in the driver).
To fix TVH with respect to the new API, I suggest to try the patch attached (untested).
Updated by Oliver O about 8 years ago
- File Status (fix applied).png Status (fix applied).png added
Change improved to avoid switching between dB and relative (%) displays in the UI.
Tested: fixes the bug as intended (see screenshot).
Fix provided as pull request #887
ยท https://github.com/tvheadend/tvheadend/pull/887
Updated by Oliver O about 8 years ago
Fix committed: https://github.com/tvheadend/tvheadend/commit/fb99e1adee13b86cbb5690198daaa7f60e141270
Tested successfully in version 4.1-2189~g3de3244~xenial.
Please close.
Updated by Mark Clarkstone about 8 years ago
- Status changed from New to Fixed
- % Done changed from 0 to 100
Oliver O wrote:
Fix committed: https://github.com/tvheadend/tvheadend/commit/fb99e1adee13b86cbb5690198daaa7f60e141270
Tested successfully in version 4.1-2189~g3de3244~xenial.
Please close.
commit:fb99e1ad