Switch to using DVB APIv5

[Stuart Auchterlonie]

DVB API v3 is depreciated, and v5 should be used with any kernel from 3.3 onwards

See ​https://linuxtv.org/docs/libdvbv5/index.html

[Stuart Auchterlonie]

Milestone renamed

[Stuart Auchterlonie]

See also #11482

[Mark Spieth <mspieth@…>]

In 55e1cac4bd249ec2e9463684a50121661af60417/mythtv:

Refs #12638: Partial support dvb v5 API

• Determine DVBT2 and S2 tuner types
• Support get signal strength, snr, ber if v3 apis do not work
• No support yet for multi standard DVBT2/T/C type frontends

[Mark Spieth <mspieth@…>]

In a3e1d0b993438c834cd2ceae04940b0ded4e6964/mythtv:

Refs #12638: DVBv5 API fix USING_DVB for close frontend

[mike.bibbings@…]

Capture Cards in mythtv-setup are broken on build (from mythbuntu ppa 30, which is master):

MythTV Version : v30-Pre-197-g9e3db8c MythTV Branch : master Network Protocol : 91 Library API : 30.20170914-2 QT Version : 5.5.1 Options compiled in:

linux profile use_hidesyms using_alsa using_oss using_pulse using_pulseoutput using_backend using_bindings_perl using_bindings_python using_bindings_php using_crystalhd using_dvb using_firewire using_frontend using_hdhomerun using_vbox using_ceton using_hdpvr using_ivtv using_joystick_menu using_libcec using_libcrypto using_libdns_sd using_libfftw3 using_libxml2 using_lirc using_mheg using_opengl using_opengl_video using_opengl_themepainter using_qtwebkit using_qtscript using_qtdbus using_taglib using_v4l2 using_x11 using_xrandr using_xv using_profiletype using_bindings_perl using_bindings_python using_bindings_php using_freetype2 using_mythtranscode using_opengl using_vaapi using_vdpau using_ffmpeg_threads using_mheg using_libass using_libxml2 using_libmp3lame

I have two tuner cards (Haupaugge WinTV Quad DVB-T/T2, and TBS-6981 dual DVB-S/S2) which were configured using mythtv 29. Note mythfrontend/backend works correctly after upgrade.

Using mythtv-setup Capture Cards none of these tuners now open, Frontend ID "Could not get card info for card /dev/dvb/adapter0/frontend0" Subtype "Unknown error"

Unfortunately nothing significant is shown in the mythtv-setup log even using mythtv-setup.real --logpath /tmp/ -v all --loglevel debug

Will attach log for what it might be worth.

[mike.bibbings@…]

mythtv-setup log

[Mark Spieth]

Thanks for testing.

None of the devices can be opened. This is the same code as before so the new code is not used.

To check for permissions, can you provide

ls -Rl /dev/dvb

and

groups

and

ps ax | grep dvb

for the user used to run mythtv-setup.real when mythbackend is not running.

Also if mythbackend is still running and dvbondemand is disabled, you also won't be able to open the devices.

[Peter Bennett]

I tested the latest master and capture card setup for my test DVB device is working fine. So I agree. it does not seem to be a code issue

[mike.bibbings@…]

output of ls -Rl /dev/dvb

mike@build-server:~/build/mythtv/mythtv$  ls -Rl /dev/dvb
/dev/dvb:
total 0
drwxr-xr-x 2 root root 120 Oct 10 11:08 adapter0
drwxr-xr-x 2 root root 120 Oct 10 11:08 adapter1
drwxr-xr-x 2 root root 120 Oct 10 11:08 adapter2
drwxr-xr-x 2 root root 120 Oct 10 11:08 adapter3
drwxr-xr-x 2 root root 120 Oct 10 11:08 adapter4
drwxr-xr-x 2 root root 120 Oct 10 11:08 adapter5

/dev/dvb/adapter0:
total 0
crw-rw----+ 1 root video 212, 1 Oct 10 11:08 demux0
crw-rw----+ 1 root video 212, 2 Oct 10 11:08 dvr0
crw-rw----+ 1 root video 212, 0 Oct 10 11:08 frontend0
crw-rw----+ 1 root video 212, 3 Oct 10 11:08 net0

/dev/dvb/adapter1:
total 0
crw-rw----+ 1 root video 212, 5 Oct 10 11:08 demux0
crw-rw----+ 1 root video 212, 6 Oct 10 11:08 dvr0
crw-rw----+ 1 root video 212, 4 Oct 10 11:08 frontend0
crw-rw----+ 1 root video 212, 7 Oct 10 11:08 net0

/dev/dvb/adapter2:
total 0
crw-rw----+ 1 root video 212,  9 Oct 10 11:08 demux0
crw-rw----+ 1 root video 212, 10 Oct 10 11:08 dvr0
crw-rw----+ 1 root video 212,  8 Oct 10 11:08 frontend0
crw-rw----+ 1 root video 212, 11 Oct 10 11:08 net0

/dev/dvb/adapter3:
total 0
crw-rw----+ 1 root video 212, 13 Oct 10 11:08 demux0
crw-rw----+ 1 root video 212, 14 Oct 10 11:08 dvr0
crw-rw----+ 1 root video 212, 12 Oct 10 11:08 frontend0
crw-rw----+ 1 root video 212, 15 Oct 10 11:08 net0

/dev/dvb/adapter4:
total 0
crw-rw----+ 1 root video 212, 17 Oct 10 11:08 demux0
crw-rw----+ 1 root video 212, 18 Oct 10 11:08 dvr0
crw-rw----+ 1 root video 212, 16 Oct 10 11:08 frontend0
crw-rw----+ 1 root video 212, 19 Oct 10 11:08 net0

/dev/dvb/adapter5:
total 0
crw-rw----+ 1 root video 212, 21 Oct 10 11:08 demux0
crw-rw----+ 1 root video 212, 22 Oct 10 11:08 dvr0
crw-rw----+ 1 root video 212, 20 Oct 10 11:08 frontend0
crw-rw----+ 1 root video 212, 23 Oct 10 11:08 net0

output of groups

mike@build-server:~$ groups
mike adm cdrom sudo dip plugdev lpadmin sambashare mythtv

output of ps ax | grep dvb

mike@build-server:~$ ps ax | grep dvb
20089 pts/0    S+     0:00 grep --color=auto dvb

Everything including mythtv-setup was working (that is how I configured the tuners in the first place using fixes/0.29 ppa)

Mike

[Peter Bennett]

You don't have the video group. Add that to your user.

[mike.bibbings@…]

Tried adding video group to my user, same problem. mythtv group already includes video. Just in case I had done something silly I did a clean install of Lubuntu 16.04.3 LTS,added mythbuntu ppa 30 and have exactly the same problem, so it seems to nothing to do with upgrade from mythtv 29. The only thing I did notice on the new install was that mariadb was installed (which does work), *ubuntu normally installs mysql, but this issue is for another time.

[J.Pilk@…]

There have been many changes here recently, but I recall seeing this problem after 'deleting all cards', only to find that a second attempt to define the same card worked.

​https://code.mythtv.org/trac/ticket/13046#comment:33

[J.Pilk@…]

I have installed the same build, with a single DVB-T/T2 auto switching usb device

New device PCTV Systems PCTV 290e @ 480 Mbps (2013:024f, interface 0, class 0)

It records in both modes but is not fully identified in mythtv-setup.real. I have not tried the effect of deleting it first; setup is as left from v29.0-40

ls -Rl /dev/dvb is as for adapter0 above, and the other responses are identical.

[Mark Spieth <mspieth@…>]

In 5acf389804547d27ddb33a9a7e1163f869c4eef4/mythtv:

Refs #12638: DVBv5 API: Fix ProbeDVBType variable usage

[Mark Spieth <mspieth@…>]

In 33356a74c1877848142e8397990ff3ca397796f4/mythtv:

Refs #12638: DVBv5 API: Scale signal strength and cnr with dB and improve logging

[mike.bibbings@…]

Retested by building from source (which was also failing previously) with the above commits from comments 18,19 mythtv-setup Capture Cards now open correctly. Note will retest on a clean install when mythbuntu ppa 30 is updated, which should be in next 24 hours or so.

Mike

[J.Pilk@…]

2:30.0~master.20171012.33356a7-0ubuntu0mythbuntu3 works for me in xenial. "All existing transports" scanned successfully. Thanks.

[jmwislez@…]

In case this transition to DVBv5 API would also cover support for Physical Layer Scrambling and multistream as supported by “professional” DVB-S2 adapters (e.g. TBS6903, TBD6908), I'm volunteering as a tester for patches (with TBS6903 pointed to 5.0W).

[stefanb2]

I just upgraded from 0.29 to 0.30 and my Hauppauge WinTV-dualHD DVB-T/T2/C USB stick stopped working as DVB-C tuner, because mythtv incorrectly tries to tune it as DVB-T2 frontend using DVB-C multiplex parameters (frequency, QAM, etc.):

2019-03-06 21:26:05.196847 W [3348/3348] CoreContext dtvmultiplex.cpp:286 (ParseDVB_T2) - DTVMux: Invalid T2 modulation system parameter '', aborting.
2019-03-06 21:26:05.196854 E [3348/3348] CoreContext recorders/dtvchannel.cpp:292 (SetChannelByString) - DTVChan[16](/dev/dvb/adapter2/frontend0): SetChannelByString(51): Failed to initialize multiplex options

Judging by the git history commit 55e1cac4bd249ec2e9463684a50121661af60417 is most likely the change that broke it (this code is repeated also in recorders/dvbchannel.cpp):

diff --git a/mythtv/libs/libmythtv/cardutil.cpp b/mythtv/libs/libmythtv/cardutil.cpp
index 79f7bcc419..ad316d0958 100644
--- a/mythtv/libs/libmythtv/cardutil.cpp
+++ b/mythtv/libs/libmythtv/cardutil.cpp
...
+#if DVB_API_VERSION >=5
...
+            switch (prop.u.buffer.data[i])
+            {
+                // TODO: not supported. you can have DVBC and DVBT on the same card
+                // The following are backwards compatible so its ok
+                case SYS_DVBS2:
+                    type = DTVTunerType::kTunerTypeDVBS2;
+                    break;
+                case SYS_DVBT2:
+                    type = DTVTunerType::kTunerTypeDVBT2;
+                    break;
+                default:
+                    break;
+            }

The comment "The following are backwards compatible so its ok" is obviously incorrect. Unfortunately there is no way to change the DVB card subtype in mythtv-setup, i.e. in effect mythtv only supports one delivery type per frontend.

I'm not sure if the following change would be acceptable, i.e. if adapter supports also DVB-C override the earlier DVB-T2 setting. I have not tested this change on my system yet:

      case SYS_DVBT2:
          type = DTVTunerType::kTunerTypeDVBT2;
          break;
+     case SYS_DVBC_ANNEX_A:
+     case SYS_DVBC_ANNEX_B:
+     case SYS_DVBC_ANNEX_C:
+         type = DTVTunerType::kTunerTypeDVBC;
+         break;

[stefanb2]

For anybody who encounters the same problem with multi-delivery-system DVB frontends, here is a quick & dirty solution I have now taken into use: commenting out the DVB-T names from the list of delivery systems in the si2168.c Linux kernel module. I.e. the frontend will now only announce DVB-C support and mythtv 0.30 is able to use it again.

--- a/drivers/media/dvb-frontends/si2168.c
+++ b/drivers/media/dvb-frontends/si2168.c
@@ -680,7 +680,7 @@ static int si2168_deselect(struct i2c_mux_core *muxc, u32 chan)
 }
 
 static const struct dvb_frontend_ops si2168_ops = {
-       .delsys = {SYS_DVBT, SYS_DVBT2, SYS_DVBC_ANNEX_A},
+       .delsys = {/*SYS_DVBT, SYS_DVBT2,*/ SYS_DVBC_ANNEX_A},
        .info = {
                .name = "Silicon Labs Si2168",
                .symbol_rate_min = 1000000,

[stefanb2]

FYI: I've submitted a ​patch proposal for the si2168 kernel module: it adds a parameter to disable the DVB-T/T2 support in the frontend.

[winfried]

Since v. 0.30 my mthbackend doesn't tune to DVB-C anymore with my Digital Devices Cine C/C2/T/T2 (V7) anymore. I suspect it may be the same problem, though I don't get a clear error message in the logs.

[Klaas de Waal]

Please try with the latest master, see ticket #13014. If there are still issues a log of both mythtv-setup and mythbackend with verbosity "-v general,record,channel,chanscan" would probably be useful.

[warpme]

Just to report issue with crappy DVBv5 drivers: tuner DVBSKY S952 (dual DVB-S2) traps kernel when backend reads S/N, BER, etc introduced in 22dba2624fb4790ede8f7cb8d48ed06c58492abb. Fortunately 4904cc1b5fb8cd9e985fae921a328fee272cab8f fixes issue.

[Klaas de Waal]

Replying to warpme comment:30 What is the Linux kernel version?

[Klaas de Waal]

Replying to warpme comment:30 The output of dvb-fe-tool, e.g. "dvb-fe-tool -a0" if adapter 0 is the problematic tuner, would be helpful as well!

[Gary Buhrmaster]

Replying to warpme:

Just to report issue with crappy DVBv5 drivers: tuner DVBSKY S952 (dual DVB-S2) traps kernel when backend reads S/N, BER, etc.

In kernel (media) drivers, or DVBSky's proprietary ones? Be sure to report the issue upstream so a broken driver can be fixed, as at some future point the mitigations may no longer be viable.

[Klaas de Waal <kdewaal@…>]

In dcb084767/mythtv:

Add t2_terrestrial_delivery_system descriptor

Add descriptors 0x7D, 0x7E and 0x7F according to ETSI EN 300 468 V1.15.1 (2016-03)
table 12, page 34 and paragraph 6.4.5.3, T2 delivery system descriptor.
Descriptor names in lower case as is done for all descriptors in MythTV.
Updated name descriptor 0x79, S2 delivery system descriptor, to match
the convention used for the other descriptors.
Also minor debug output change and typo fix.

Refs #12638

[Klaas de Waal <kdewaal@…>]

In 22dba2624/mythtv:

Read signal strength, bit error rate, etc with the DVBv5 API.

Read signal strength, signal to noise ratio, bit error rate and
the uncorrected block count now first with the DVBv5 API calls;
if that fails then try with the DVBv3 API calls.
Removed conditional compilation based on the DVB API version.
Previously this was done first with the DVBv3 and then with
the DVBv5 calls if the DVBv5 code was compiled in.

Refs #12638

[Klaas de Waal <kdewaal@…>]

In 4904cc1b5f/mythtv:

Read signal strength etc with DVBv3 first

Read signal strength, bit error rate, signal to noise ratio
and uncorrect block count now first with the DVBv3 API calls
and if these are not supported try it with the DVBv5 API calls.
Reason is reported Linux kernel crashes caused by the
previous change to do the DVBv5 API calls first.
Also some improvements in the DVBv5 version of the code
including added debug log output.

Refs #12638

[Klaas de Waal <kdewaal@…>]

In 4904cc1b5f/mythtv:

Read signal strength etc with DVBv3 first

Read signal strength, bit error rate, signal to noise ratio
and uncorrect block count now first with the DVBv3 API calls
and if these are not supported try it with the DVBv5 API calls.
Reason is reported Linux kernel crashes caused by the
previous change to do the DVBv5 API calls first.
Also some improvements in the DVBv5 version of the code
including added debug log output.

Refs #12638

[Klaas de Waal <kdewaal@…>]

In 4904cc1b5f/mythtv:

Read signal strength etc with DVBv3 first

Read signal strength, bit error rate, signal to noise ratio
and uncorrect block count now first with the DVBv3 API calls
and if these are not supported try it with the DVBv5 API calls.
Reason is reported Linux kernel crashes caused by the
previous change to do the DVBv5 API calls first.
Also some improvements in the DVBv5 version of the code
including added debug log output.

Refs #12638

[Klaas de Waal <kdewaal@…>]

In 4904cc1b5f/mythtv:

Read signal strength etc with DVBv3 first

Read signal strength, bit error rate, signal to noise ratio
and uncorrect block count now first with the DVBv3 API calls
and if these are not supported try it with the DVBv5 API calls.
Reason is reported Linux kernel crashes caused by the
previous change to do the DVBv5 API calls first.
Also some improvements in the DVBv5 version of the code
including added debug log output.

Refs #12638

[winfried]

My excuses for the delay, I didn't have time to compile master and test it before. But I can confirm that with yesterdays master both mythttv-setup and the backend are correctly opening my digital devices / sony DVB-T/T2/C/C2 card.

[Klaas de Waal]

To the best of my knowledge MythTV does now use the DVBv5 API everywhere. The known exception is the signal strength etc. readout which is first tried with DVBv3 and if that fails it is done with DVBv5. This gives minor differences on some cards but as the reverse order is reported to give incidental but severe problems this is something I do not intend to change in the short term.

If nothing comes up which needs fixing before the v31 release then I intend to close this ticket.

[Klaas de Waal <klaas@…>]

In 83d8bbc825/mythtv:

Fallback for modulation system setting with DVB-T/T2 and DVB-S/S2

The checks on the correct modulation system setting in dvt_multiplex is
now more relaxed; if there is no value defined then a suitable default is chosen.
This eases migration from old mythtv installations to v31.
Also changed default selection to DVB-T2 and DVB-S2 in popup menu's.

Refs #13472
Refs #12638