Kernel modules missing for the PCTV 292e DVB stick

Hi OSMC Team,

I just got my shiny new Vero 4k as an upgrade over my Pi3. The reason why I wanted to upgrade was the 4k’s H.256 support I need in order use one of the most widely used and typically best supported DVB-T sticks, the PCTV 292e which I previously tested with OSMC on my Pi3.

Unfortunately the Vero 4k currently lacks the required kernel driver modules for the em28xx family as well as a few others provided out of the box with OSMC for the RaspPi, like si2157.ko, si2168.ko. Why are these missing from the Vero 4k image? How to get them? Do I have to build a custom kernel on the Vero itself (to avoid a cross-build)?

Without support for that stick the Vero is more or less useless for me :sweat:



Can you run lsusb (you need to sudo apt-get install usb-Utop’s) first, then I can look in to this for you


I think sam’s autocorrect has gone off… Should be sudo apt-get install usbutils

Yep, I know :wink:. Here you go: Bus 001 Device 003: ID 2013:025f PCTV Systems

Here’s the list of modules used by that device on the RaspPi OSMC image:

dvb_core              104651  1 em28xx_dvb
em28xx                 80422  2 em28xx_dvb,em28xx_rc
em28xx_dvb             25108  0
em28xx_rc               9960  0
evdev                  13192  1
i2c_mux                 3163  1 si2168
media                  18006  1 videodev
rc_core                25745  3 em28xx_rc,rc_pinnacle_pctv_hd
rc_pinnacle_pctv_hd     1267  0
si2157                  5638  1
si2168                  8689  1
tveeprom               14115  1 em28xx
uinput                  9818  0
v4l2_common             6578  1 em28xx
videodev              210827  2 em28xx,v4l2_common

I can’t find many of those on the Vero but they might of course be compiled into the kernel for some reason.


Hi Sam,

Unfortunately the situation is even worse. The PCTV 292e is the successor of the ubiquitous 290e and thus got official (initial) Linux support only as of kernel 3.16 (“improved a lot since then”). However, while the Pi image uses kernel 4.4 the Vero is still on 3.14 which obviously doesn’t support this device at all - so it’s not just a matter of enabling a few modules, I need a new kernel entirely :cold_sweat:

Is there any way to get this officially supported? I mean the use case for the Vero being used with a DVB device should be very common and device support should thus be as wide as possible, i.e. an up-to-date kernel (like in the Pi image) would just make the otherwise great Vero 4k the perfect device. IOW, please make it truly “the best way to experience OSMC” :wink:


We can backport any needed modules, please give us a little bit of time…

A new kernel is not needed.


Phew, that’s great news. Thanks Sam!

OTOH, why going through the hassle of manually backporting individual drivers? Wouldn’t it be easier (less costly!), less error-prone and even more useful (see use case above) to just upgrade the kernel? What’s holding it back? Can one compile a custom kernel, based on the existing config of course, or is the current kernel heavily patched?

Thanks again!

PS: the Vero works great so far, incl. settings restore (from Pi), S/PDIF, various HD formats and overall performance. Great job indeed!

It’s not as simple as updating the kernel unfortunately, as the SoC prevents this. We will have a mainline 4.x kernel in the future.

We are also focused on stability: the current kernel is very tested.

I’ll let you know when I have something to test.


Understood. Ideally as a deb package since flashing a complete image would kill other installed services.


Just to give other readers some context: the Vero 4K uses an Amlogic S905X SoC which, while being very interesting hardware-wise for projects like this, are a major (yet known) PITA when it comes to software support. This is due to the fact that the companies building those Mali SoCs simply don’t open source their software such that the Linux kernel developers can provide mainline kernel support themselves. That said, Sam depends on Amlogic to provide a newer upstream kernel buildroot and up to now there’s only version 3.14.29 available :disappointed:. I knew all that since my search for a new device (e.g. the CuBox-i or ODROID-C2) to replace my Pi3 but I somehow managed to neglect that fact when I learned about the Vero 4K - just loved it and wanted to support OSMC!

Anyhow, there are indications that Amlogic might update the kernel to 4.4 at some point but even their current Android 7.0 (Nougat) efforts are still based on 3.14, so it will presumably take a while until 4.4 will be available. The community is currently trying to work with Amlogic to change their stance on open sourcing their code but it’s questionable that the situation will improve dramatically any time soon. Sam, please chime in if you know better.

Do you have a rough estimate on this? Is it days, weeks or even months? I don’t mean to put pressure on you guys, it’s just for my planning :innocent: Also, please let me know if I can be of any further help.

Update: A few hints for backporting:

  • USB Interface
  • Main commit adding initial support for the 292e: 1922924
  • Other kernel commits related to the 292e: GitHub search
  • Demodulator
  • Main commit adding initial support for the Silicon Labs Si2168-40: 845f350
  • More related commits: GitHub search
  • Tuner
  • Main commit adding initial support for the Silicon Labs Si2157-30: 930a873
  • More related commits: GitHub search
  • Firmware: canonical version available at OpenELEC
  • LinuxTV wiki

That’s what I meant by “improved a lot” since the initial release in 3.16 :unamused: Do you still think it’s feasible?



AMLogic are actually very good at providing sources when compared to other SoC vendors. The actual issue is as you have noted, that the BSP kernel is a little old now.

AMLogic mainlining efforts are already underway and there have been a lot of milestones reached. When things get nearer, we’ll do testing and then get this included for OSMC. However – we still use 4.4 for RBP / Vero 1, and 4.2 for AppleTV. I prefer to stick with a stable kernel once they’ve matured and only maintain critical fixes and improvements.

I think we can get some improvements for testing ready by early April and then include them in OSMC’s April update. We can backport DVB modules from 4.4.

Stay tuned.


That’s good to hear!

That’s what I figured but it’s not that easy to get some insight.

Which is the right thing to do, for obvious reasons. I didn’t mean to suggest to use bleeding edge kernels instead.

That’d be awesome :beers:

Thanks Sam!

Hi @Sam,

thanks for backporting the relevant drivers in the May update! My DVB stick finally seems to be recognized properly now:

[    4.220437] em28xx 1-2:1.0: New device PCTV PCTV 292e @ 480 Mbps (2013:025f, interface 0, class 0)
[    4.220449] em28xx 1-2:1.0: DVB interface 0 found: isoc
[    4.220531] em28xx 1-2:1.0: chip ID is em28178
[    6.214766] em28xx 1-2:1.0: EEPROM ID = 26 00 01 00, EEPROM hash = 0xa81bf604
[    6.214778] em28xx 1-2:1.0: EEPROM info:
[    6.214784] em28xx 1-2:1.0: 	microcode start address = 0x0004, boot configuration = 0x01
[    6.221401] em28xx 1-2:1.0: 	AC97 audio (5 sample rates)
[    6.221414] em28xx 1-2:1.0: 	500mA max power
[    6.221421] em28xx 1-2:1.0: 	Table at offset 0x27, strings=0x146a, 0x1888, 0x0a7e
[    6.221635] em28xx 1-2:1.0: Identified as PCTV tripleStick (292e) (card=94)
[    6.221644] em28xx 1-2:1.0: dvb set to isoc mode.
[    6.221982] usbcore: registered new interface driver em28xx
[    6.324127] em28xx 1-2:1.0: Binding DVB extension
[    6.350975] si2168 2-0064: Silicon Labs Si2168-B40 successfully identified
[    6.350980] si2168 2-0064: firmware version: B 4.0.2
[    6.454257] si2157 3-0060: Silicon Labs Si2147/2148/2157/2158 successfully attached
[    6.454303] dvbdev: DVB: registering new adapter (1-2:1.0)
[    6.454314] em28xx 1-2:1.0: DVB: registering adapter 0 frontend 0 (Silicon Labs Si2168)...
[    6.454329] dvbdev: dvb_create_media_entity: media entity 'Silicon Labs Si2168' registered.
[    6.455426] dvbdev: dvb_create_media_entity: media entity 'dvb-demux' registered.
[    6.458404] em28xx 1-2:1.0: DVB extension successfully initialized
[    6.458418] em28xx: Registered (Em28xx dvb Extension) extension
[   17.088958] si2168 2-0064: downloading firmware from file 'dvb-demod-si2168-b40-01.fw'
[   17.294328] si2168 2-0064: firmware version: B 4.0.11
[   17.299239] si2157 3-0060: found a 'Silicon Labs Si2157-A30'
[   17.347679] si2157 3-0060: firmware version: 3.0.5

However, we’re not quite there yet as each mux scan fails with the following error:

2017-06-12 11:25:42.011 mpegts: 498MHz - tuning on Silicon Labs Si2168 : DVB-T #0
2017-06-12 11:25:42.011 linuxdvb: Silicon Labs Si2168 : DVB-T #0 - DTV_CLEAR failed [e=Inappropriate ioctl for device]

My educated guess would be that this is due to the platform mismatch between Tvheadend (32 bit) and the kernel driver (64 bit), with a potential patch available. That, however, should affect all drivers so it’s unlikely to be the root cause, right?. I also checked the device file permissions and they’re correct (r/w for group video which user osmc is a member of).

Any idea?


Hi @brevilo

I’m glad to see that the driver for your adapter is now included and
is being picked up with the new update.

That patch has been in for some time. Checking the DVB backports shows that it’s included if we build with CONFIG_COMPAT=y, which we do.

This needs some further investigation.


Sure, let me know if I can be of any further help.


Oh, and for the sake of completeness: you want to include this firmware in the Vero image for full support of this DVB device. I installed it manually earlier and haven’t since checked whether it’s now included.

At some point we definitely need to revisit
firmware for DVB and include more in OSMC. But I want
to make it part of a separate package to try and avoid bloating
the filesystem if possible


Sure, whatever you see fit. Just mentioned it cause you asked for it on another thread IIRC :innocent:

That patch has been in for some time. Checking the DVB backports shows that it’s included if we build with CONFIG_COMPAT=y, which we do.

Am I right you refer to this commit?