Hi guys,
after I settled my earlier DVB-T issues by simply buying the official OSMC DVB-T stick (when it finally became available) and throwing away my original solution, I now had to move on to DVB-S - and the same story seems to repeat itself. Quite a while ago I tried to come up with a round-up of supported DVB-S dongles. Now it was about time to buy some, so I got two “Sundtek SkyTV Ultimate 8” hoping they would be supported out of the box.
Alas! That would have been way too easy. Unfortunately the Sundtek driver/software is only available for arm64, not armv7/armhf, which makes them incompatible with the Vero userland, it seems. Tvheadend just doesn’t recognize the existing (and working) DVB adapter devices. This 32 vs. 64 bit issue clearly rings a bell from the yesteryears.
Is there are any way to either switch my Vero to run a full arm64 userland or to at least fix the dependencies of the aarch64-tvheadend-app-osmc package such that it can be installed alternatively to the armv7-tvheadend-app-osmc. Right now, that’s not possible due to unmet dependencies (missing firmware package I don’t care about, unresolvable conflicts).
Don’t get me wrong, I love my Vero, OSMC in general and @sam_nazarko 's dedication but these DVB dongle “adventures” are a real PITA.
Cheers
I have been searching for a DVB-S solution for years so please post if you do manage to find a working option.
Ideally, Sundtek would produce an armhf version. I came across this thread from February 2018: osmc vero4 drivers install problem but clearly it’s not been resolved satisfactorily.
It is usually preferable if you actually show what’s going wrong. I did try to install it myself:
osmc@osmc-4k:~$ sudo apt-get install aarch64-tvheadend-app-osmc --dry-run
Reading package lists... Done
Building dependency tree
Reading state information... Done
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:
The following packages have unmet dependencies:
aarch64-tvheadend-app-osmc:arm64 : Depends: dvb-firmware-osmc:arm64 but it is not installable
Depends: python-minimal:arm64 but it is not going to be installed
Depends: gzip:arm64 but it is not going to be installed
E: Unable to correct problems, you have held broken packages.
Taking gzip:arm64 as a random example:
osmc@osmc-4k:~$ sudo apt-get install gzip:arm64 --dry-run
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following additional packages will be installed:
gcc-6-base:arm64 libc6:arm64 libgcc1:arm64
Suggested packages:
glibc-doc:arm64 locales:arm64
The following packages will be REMOVED:
gzip
The following NEW packages will be installed:
gcc-6-base:arm64 gzip:arm64 libc6:arm64 libgcc1:arm64
WARNING: The following essential packages will be removed.
This should NOT be done unless you know exactly what you are doing!
gzip
0 upgraded, 4 newly installed, 1 to remove and 11 not upgraded.
Inst gcc-6-base:arm64 (6.3.0-18+deb9u1 Debian:9.11/oldstable, Debian-Security:9/oldstable [arm64])
Conf gcc-6-base:arm64 (6.3.0-18+deb9u1 Debian:9.11/oldstable, Debian-Security:9/oldstable [arm64])
Inst libc6:arm64 (2.24-11+deb9u4 Debian:9.11/oldstable [arm64]) []
Inst libgcc1:arm64 (1:6.3.0-18+deb9u1 Debian:9.11/oldstable, Debian-Security:9/oldstable [arm64])
Conf libgcc1:arm64 (1:6.3.0-18+deb9u1 Debian:9.11/oldstable, Debian-Security:9/oldstable [arm64])
Conf libc6:arm64 (2.24-11+deb9u4 Debian:9.11/oldstable [arm64])
Remv gzip [1.6-5+b1]
Inst gzip:arm64 (1.6-5+b1 Debian:9.11/oldstable [arm64])
Conf gzip:arm64 (1.6-5+b1 Debian:9.11/oldstable [arm64])
The lines " WARNING: The following essential packages will be removed.
This should NOT be done unless you know exactly what you are doing!
gzip" don’t sound very encouraging.
I did come across this post from Sam:
Vero 4K can run armhf and arm64 packages side by side, e.g. sudo apt-get install gcc:arm64 .
osmc@osmc-4k:~$ sudo apt-get install gcc:arm64 --dry-run
Reading package lists... Done
Building dependency tree
Reading state information... Done
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:
The following packages have unmet dependencies:
gcc:arm64 : Depends: cpp:arm64 (>= 4:6.3.0-4) but it is not going to be installed
Depends: gcc-6:arm64 (>= 6.3.0-9~) but it is not going to be installed
E: Unable to correct problems, you have held broken packages.
So more of the same kind of problems. Trying to install gcc-6 fails the same way. I think Sam will need to advise on this one.
Sundtek must produce an armhf version because it works on Pi.
Most likely their script is checking arch or uname which returns the kernel bit depth and not the userland bit depth. Either override with setarch or adjust their install script accordingly.
We also have a ioctl compat layer so both aarch64 and armhf binaries can use the DVB stack without issues; but it is my understanding that Sundtek don’t interface with DVB directly as an attempt to support their dongle without a versioned kernel module, and therefore support a wider range of kernels without needing to use a solution like DKMS which would have its own problems.
Sundtek must produce an armhf version
That’s the ideal solution and I’m certainly going to pursuit that! Yet we ran into these architecture issues with other dongles, too, so it might indeed be useful to others as well to get at least Tvheadend (aarch64) installable.
Most likely their script is checking arch or uname which returns the kernel bit depth and not the userland bit depth
That’s correct and I had tried that already. Unfortunately there doesn’t seem to be an armv7/armhf build anywhere on their download servers.
Sundtek don’t interface with DVB directly
That’s most likely correct as well. I haven’t yet fully understood how their stack works, but there’s definitely no kernel module involved. They just spawn their stuff via a mediaclient which creates all the necessary device nodes. Yet those don’t work across architectures.
Cheers
I came across this thread from February 2018: osmc vero4 drivers install problem but clearly it’s not been resolved satisfactorily.
Yep, I saw that earlier. I’m going to resurrect that thread as soon as my account request (yes, that’s a thing) got confirmed for that forum.
There must be, because it works with RPi.
If memory serves, the interface is compiled dynamically and not as a package.
I have a Sundtek dongle, and it works on armhf (Raspberry Pi) as well as Vero 4K, but it’s been some time since I tested it.
You do not need an aarch64 version of TVHeadend, especially if it does not use a kernel module. The issue with media_build and 64-bit to 32-bit pointer dereferencing was fixed over two years ago, but this would not apply to the Sundtek approach.
Everything needed for the Sundtek to work is already there, you just need to change the arch in the script or setarch…
As suspected – there’s an arch mismatch there.
You just need to hardcode armhf and it will work fine.
Believe me, I tried that. If you have a look at their install script, it lists the following archs:
armsysv
armoabi
x86 32bit
x86 32bit23
x86 64bit
android
mips
openwrtmipsr2
mipsel
dreambox
mipsel2
ppc32
ppc64
-
arm64 isn’t listed but works
- neither armhf nor armv7 work (can’t be downloaded, 404)
- I’d tried armsysv and armoabi (useless on armhf) but ld also complained about a arch/ELF mismatch, as with arm64
Now I’m really wondering where their RPi stack comes from. Are you sure you’re talking about the Sundtek DVB-S dongle, not the DVB-T dongle some here use on the RPi? They could have different driver packages. I’ll have another look…
It’s an S2 dongle.
There is very clearly armhf support in the script:
f_checkarmhf() {
if [ -e /lib/ld-linux-armhf.so.3 ]; then
if [ ! -e /lib/ld-linux.so.3 ]; then
ln -s /lib/ld-linux-armhf.so.3 /lib/ld-linux.so.3
fi
/$tmp/.sundtek/chkarmsysvhf 1>/dev/null 2>&1
if [ "$?" != "0" ]; then
return 1
fi
echo "ARM SYSV HF System detected"
if [ -e /proc/bus/nim_sockets ]; then
STBSYSTEM=1
echo "This seems to be a settopbox, also installing Settopbox extensions"
fi
SYSTEM="armsysvhf"
return 0
fi
return 1
}
So set your arch to armsysv… (override SYSTEM parameter at the end of all the checks)
To reiterate: there’s nothing for Sundtek to do or release. The support is already there and it works.
Ok, in the meantime I tried the armsysv build again, as that’s the only reasonable candidate in that list. And yes, it seems to be the right one:
libmediaclient.so: ELF 32-bit LSB shared object, ARM, EABI4 version 1 (SYSV), dynamically linked, stripped
Now I need to fix the remaining ld preload error:
ERROR: ld.so: object '/opt/lib/libmediaclient.so' from /etc/ld.so.preload cannot be preloaded (cannot open shared object file): ignored.
This is indeed a different error as the ELF/ABI mismatches I saw for the other builds - duh! Looking into it. We’re close…
Hm, the ELF header of /opt/lib/libmediaclient.so and /usr/bin/tvheadend look fine/identical, yet the file attributes differ:
/opt/lib/libmediaclient.so:
Tag_CPU_name: "ARM9TDMI"
Tag_CPU_arch: v4T
Tag_ARM_ISA_use: Yes
Tag_THUMB_ISA_use: Thumb-1
Tag_ABI_PCS_wchar_t: 4
Tag_ABI_FP_denormal: Needed
Tag_ABI_FP_exceptions: Needed
Tag_ABI_FP_number_model: IEEE 754
Tag_ABI_align_needed: 8-byte
Tag_ABI_align_preserved: 8-byte, except leaf SP
Tag_ABI_enum_size: int
Tag_ABI_optimization_goals: Aggressive Speed
/usr/bin/tvheadend:
Tag_CPU_name: "7-A"
Tag_CPU_arch: v7
Tag_CPU_arch_profile: Application
Tag_ARM_ISA_use: Yes
Tag_THUMB_ISA_use: Thumb-2
Tag_FP_arch: VFPv3-D16
Tag_ABI_PCS_wchar_t: 4
Tag_ABI_FP_rounding: Needed
Tag_ABI_FP_denormal: Needed
Tag_ABI_FP_exceptions: Needed
Tag_ABI_FP_number_model: IEEE 754
Tag_ABI_align_needed: 8-byte
Tag_ABI_align_preserved: 8-byte, except leaf SP
Tag_ABI_enum_size: int
Tag_ABI_VFP_args: VFP registers
Tag_CPU_unaligned_access: v6
It’s obvious though, that /opt/bin/mediaclient fails to run as long as /opt/lib/libmediaclient.so isn’t preloaded. FYI, by “fails” in mean this, even when setting LD_PRELOAD explicitly (I commented out the entry in /etc/ld.so.preload):
$ LD_PRELOAD=/opt/lib/libmediaclient.so /opt/bin/mediaclient --start=4
-bash: /opt/bin/mediaclient: No such file or directory
Yes, the path is correct and the file is executable (755), go figure…
Oh, just noticed this in the ELF header of /opt/lib/libmediaclient.so:
Flags: 0x4000002, Version4 EABI, <unknown>
It doesn’t mention hard-float ABI so it might not be an armhf build after all…?
Progress! There’s an undocumented armsysvhf build “hidden” in the install script! Just run the installer with the option -system armsysvhf and you get what the Vero needs 
But… Tvheadend still doesn’t see the adapters, despite this:
FRONTEND: /dev/dvb/adapter0/frontend0
DVR: /dev/dvb/adapter0/dvr0
DMX: /dev/dvb/adapter0/demux0
Any idea? (see below)
The adapters are probably cached and you need to clean the tuner cache.
Also try rebooting.
Tried rebooting a couple of times. How do I scrub the tuner cache manually?
Finally!!! 
Marking the hidden option above as solution.
@Xanderzdad : at your service 
2 Likes
Glad it’s working now. I’m sure this will help others in the future too.