Opened 6 years ago
Closed 6 years ago
Last modified 5 years ago
#13386 closed Patch - Bug Fix (Fixed)
No Signal/Noise and Signal Strength with MyGica T230 DVB tuner
Reported by: | Klaas de Waal | Owned by: | Klaas de Waal |
---|---|---|---|
Priority: | minor | Milestone: | 30.1 |
Component: | MythTV - DVB | Version: | Master Head |
Severity: | medium | Keywords: | DVBv5 channelscan |
Cc: | Stuart Auchterlonie, mspieth | Ticket locked: | no |
Description
A channelscan with mythtv-setup of the DVB-T signal with a new Geniatech/Mygica? T230 tuner does work, but the "Scanning" screen only shows the "Scan Progress"; the "Signal/Noise?" and the "Signal Strength" are zero.
The mythtv-setup log shows that also the bit error rate and the uncorrected block count are missing:
2019-01-22 16:19:21.192483 W DVBSigMon[15](/dev/dvb/adapter2/frontend0): Cannot measure Signal Strength eno: Unknown error 524 (524) 2019-01-22 16:19:21.192514 E DVBChan[15](/dev/dvb/adapter2/frontend0): Getting Frontend signal/noise ratio failed. eno: Unknown error 524 (524) 2019-01-22 16:19:21.192530 W DVBSigMon[15](/dev/dvb/adapter2/frontend0): Cannot measure S/N eno: Unknown error 524 (524) 2019-01-22 16:19:21.192550 E DVBChan[15](/dev/dvb/adapter2/frontend0): Getting Frontend signal error rate failed. eno: Unknown error 524 (524) 2019-01-22 16:19:21.192564 W DVBSigMon[15](/dev/dvb/adapter2/frontend0): Cannot measure Bit Error Rate eno: Unknown error 524 (524) 2019-01-22 16:19:21.192584 E DVBChan[15](/dev/dvb/adapter2/frontend0): Getting Frontend uncorrected block count failed. eno: Unknown error 524 (524) 2019-01-22 16:19:21.192599 W DVBSigMon[15](/dev/dvb/adapter2/frontend0): Cannot count Uncorrected Blocks eno: Unknown error 524 (524)
The code in dvbchannel.cpp tries to retrieve the values for signal strength etc. first with a DVBv3 ioctl call (DVBv3) and if that fails with the EOPNOTSUPP error code then a DVBv5 call is used.
This is implemented in MythTV by mspieth on October 7, 2017 as part of ticket #12638:
https://github.com/MythTV/mythtv/commit/55e1cac4bd249ec2e9463684a50121661af60417#diff-0f5669f105cc36674c93770abb47cac4
However, on December 12, 2017 the EOPNOTSUPP error code is changed into ENOTSUPP as found in the Linux kernel:
https://github.com/torvalds/linux/commit/330dada5957e3ca0c8811b14c45e3ac42c694651#diff-a1c3a3d76c7728571c3d629e052b8f1e
The solution is to add a test on the ENOTSUPP error code; the test on EOPNOTSUPP must stay there for users who run older Linux kernels.
N.B. A complication is that the ENOTSUPP error code is not defined in any include file in "userland".
Therefore, the attached patch locally defines ENOTSUPP to 524.
An alternative fix could be to remove the test on ioctl error code completely and always try the DVBv5 call if the DVBv3 call fails, not only if the specific error code is given.
The patch contains two additional minor fixes:
- initialization of "fe_status_t status" variable in function wait_for_backend; this is already done like this in function HasLock?.
- millisecond to seconds+microseconds conversion in function wait_for_backend around line 1500. The original code is correct for time values up to 999 milliseconds but not for larger values.
Test configuration:
- Linux Fedora 29, kernel 4.20.3-200.fc29.x86_64
- Tuner MyGica? DVB-T2 HDTV USB Stick T230
- MythTV master.
- Scan of DVB-T signal Digitenne in Europe/The? Netherlands
Attachments (2)
Change History (13)
Changed 6 years ago by
Attachment: | 20190126-dvbchannelscan-dvbv5.patch added |
---|
comment:1 Changed 6 years ago by
Milestone: | needs_triage → 30.1 |
---|---|
Status: | new → infoneeded_new |
comment:2 Changed 6 years ago by
Hi Stuart,
There is no timeout value change in the patch. However, there is a fix in the function wait_for_backend where a timeout value in milliseconds is converted to seconds and microseconds. I assume that is what you refer to.
This is the part of the patch:
@@ -1494,7 +1499,8 @@ static void drain_dvb_events(int fd) */ static bool wait_for_backend(int fd, int timeout_ms) { - struct timeval select_timeout = { 0, (timeout_ms % 1000) * 1000 /*usec*/}; + struct timeval select_timeout = { timeout_ms / 1000, (timeout_ms % 1000) * 1000 /*usec*/}; + fd_set fd_select_set; FD_ZERO( &fd_select_set); FD_SET (fd, &fd_select_set);
In the original code the number of seconds is set to zero. This means the function will not work correct for timeout values of 1 second or more.
This is not yet a problem because the function is currently only being called with a timeout value of 50 milliseconds but nevertheless it is wrong and it could give surprises if the timeout value is ever changed.
I can make a separate ticket for this if that is appreciated.
Regards, Klaas.
Changed 6 years ago by
Attachment: | 20190128-dvbchannelscan-dvbv5.patch added |
---|
Patch without the change to the timeout value computation, as requested by Stuart.
comment:4 Changed 6 years ago by
Created ticket #13392, Incorrect time conversion in dvbchannel.cpp, for the timeout value conversion from milliseconds to seconds/microseconds in function wait_for_backend.
comment:5 Changed 6 years ago by
My understanding is that this bug does not only affect tuners that use the si2168 chip such as the MyGica? T230 but that all DVB tuners that do not support the dvbv3 ioctl functions will not show the signal strength etc anymore when using a recent Linux kernel.
comment:6 Changed 6 years ago by
Owner: | set to Stuart Auchterlonie |
---|---|
Status: | infoneeded_new → assigned |
comment:7 Changed 6 years ago by
Owner: | changed from Stuart Auchterlonie to Klaas de Waal |
---|
comment:8 Changed 6 years ago by
Resolution: | → Fixed |
---|---|
Status: | assigned → closed |
In commit to master 9a174ff (commit 9a174ffc3fbd747bc6456a6e620a631793c9fbf2)
No Signal/Noise? and no Signal Strength with Si2168-based tuners
The Linux driver for the Si2168 only implements the DVBv5 calls to retrieve the signal strength etc. The MythTV code first tries the DVBv3 call and if that fails with an EOPNOTSUPP then the DVBv5 call is tried. This worked correct until Linux kernel changed the error code from EOPNOTSUPP to ENOTSUPP (value 524). This fix adds a test on ENOTSUPP in addition to the existing test on EOPNOTSUPP.
Fixes #13386
comment:9 Changed 5 years ago by
Hello. Would you be able to backport this to v30 too? I am affected by this "unknown error 524" in v30 and am not in a position to upgrade to v31 yet.
There appears to be a timeout change in the patch as well.
Was this intentional?
Regards Stuart