Sundtek Support Forum

I still cannot understand why the system gives those errors. Here's the summary.

New TVHeadend version and dynamic loader for arm:
# file ./tvheadend
../tvheadend: ELF 32-bit LSB shared object, ARM, EABI5 version 1 (GNU/Linux), dynamically linked (uses shared libs), for GNU/Linux 3.2.0, BuildID[sha1]=92d8e0271ca790df2a030939e0dded2b4d2cff71, not stripped
# file ./ld.so
ld.so: ELF 32-bit LSB shared object, ARM, EABI5 version 1 (SYSV), dynamically linked, BuildID[sha1]=4e62b2761d7a64fc51fd22235cff9e0ce5fccaa3, stripped
To use the Sundtek tuner by preloading the library with this TVHeadend, the only version that works armsysv, which is the following (EABI4):
# file ./libmediaclient.so
/share/CACHEDEV1_DATA/.qpkg/TVH_Dev_Sundtek/sundtek/opt/lib/libmediaclient.so: ELF 32-bit LSB shared object, ARM, EABI4 version 1 (SYSV), dynamically linked, stripped... but it gives errors when using for example Busybox system commands like echo, etc.; this is the Busybox version:
# file /bin/busybox
/bin/busybox: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux-armhf.so.3, for GNU/Linux 3.1.1, BuildID[sha1]=77fd9f8a8a41b7511e636baa7842fd441a392944, stripped
The armsysvhf version of the library, instead, doesn't work with TVHeadend because it doesn't find /dev and it's the following:
# file libmediaclient.so
libmediaclient.so: ELF 32-bit LSB shared object, ARM, EABI5 version 1 (SYSV), dynamically linked, stripped
I'm pretty confused about this situation, because I though that EABI5 version 1 should work everywhere but this is not the case. Maybe the difference is the tag GNU/Linux instead of SYSV? I don't know...
I'll try to use LD_PRELOAD directly on the Linux loader instruction, instead of exporting the environment variable (which then applies also to other Busybox commands) to avoid the errors, but it's really a behaviour that I would like to understand. And Google doesn't seem to be my friend this time

OK, I'm on the chat!

Sorry if I write here, but I don't understand Deutsche
I'm preparing the QNAP QPKG for the Streaming Server, and it's almost done, but I have a question. The database where the playlist and/or channels are saved where is located?

I tried strace-ing rtspd but still I was unable to figure out where it is.

EDIT: It was under my eyes... /opt/bin/sundtek.db!
Can I change this PATH to something else, maybe in the QPKG folder? How? I don't like having it hardcoded, especially in /opt which may not exist on the QNAP.

Unfortunately is seems as if the development of the QNAP driver package for 64bit now got stuck, because the developer of the QNAP package (virtualdj) is missing feedback in this thread.

We continued this discussion in the chatroom as far as I remember (that's why it did not continue here).

I confirm. I was in contact with the developer via IRC and I did a simple test on my 64-bit NAS.
Unfortunately, due to the missing libraries on the QNAP, it's not possible to use the Sundtek package in 64-bit mode (hence with 64-bit TVHeadend) without preloading all the binaries with LD_LIBRARY_PATH.

I told the developer that I would have tried to make a 64-bit QPKG with this method, but then I realized that there are no real advantages on doing all that stuff.

I'd like to continue using the stick & NAS in a stable environment and use future updates of the 64bit tvheadend package.

Installing TVHeadend 32-bit with TVH_Dev_Sundtek 32-bit solves the issue and should not cause any crashes (or at least they should not be related to the fact the applications are running in 32-bit mode).

As TVHeadend is not using a lot of RAM (it runs on a NAS), there isn't any drawback to stick with 32-bit mode. QNAP in fact use all the applications in that mode (otherwise the libraries would be available) and keeps the kernel with 64-bit to support large volumes (HDD).

Thanks, exporting LD_LIBRARY_PATH is always an hassle and I removed it from TVHeadend QPKG too.

Hi, I'm the same virtualdj user of the QNAP forum.
If you follow the main TVHeadend thread on the QNAP forums you may have known that TVHeadend application is now a fully 64-bit application.

So, thanks to QNAP that provided me a 64-bit NAS to test, I'm trying to develop a further version of the Sundtek QPKG to support TVHeadend in 64-bit mode. In fact, at the moment the only possible way is running TVHeadend 32-bit with the 32-bit flavour of the Sundtek drivers.

Now I understand because you asked me to update the script to support DVBLink package!

At first I tried installing the latest TVH_Dev_Sundtek QPKG and I found I cannot run mediaclient or the other bins.
[/share/CACHEDEV1_DATA/.qpkg/TVH_Dev_Sundtek/opt/bin] # mediaclient
mediaclient: error while loading shared libraries: librt.so.1: wrong ELF class: ELFCLASS32
That's due to QNAP which does not supply all the complete 64-bit libraries:
[/share/CACHEDEV1_DATA/.qpkg/TVH_Dev_Sundtek/opt/bin] # ldd mediasrv
        linux-vdso.so.1 =>  (0x00007fff1cdfe000)
        libdl.so.2 => not found
        libpthread.so.0 => /lib64/libpthread.so.0 (0x00007fd4cfff9000)
        librt.so.1 => not found
        libc.so.6 => /lib64/libc.so.6 (0x00007fd4cfc76000)
        /lib64/ld-linux-x86-64.so.2 (0x00007fd4d0216000)
[/share/CACHEDEV1_DATA/.qpkg/TVH_Dev_Sundtek/opt/bin] # ls /lib64/
ld-2.11.1.so*         libc.so.6*
ld-linux-x86-64.so.2@ libpthread.so.0*
So, to run mediaclient or mediasrv both libdl.so.2 and librt.so.1 are needed, hence you used LD_LIBRARY_PATH to borrow them from the DVBLink package.
I also had to ship those libraries (and actually the complete libc) with TVHeadend as it didn't run without them. We can use the same principle with TVHeadend, but I don't like this very much.

So I'm asking: what do you think if we build a QPKG specifically for 64-bit with the two libraries shipped with the QPKG, so that mediaclient can use them and TVH_Dev_Suntek will became standalone again?

I'm asking here because I can of course create a script that sets LD_LIBRARY_PATH before running mediaclient or mediasrv, but I prefer to not use LD_LIBRARY_PATH if possible.
So, do you think you can build the mediaclient, mediasrv and libmediaclient.so files (and others as well) compiled with:
LD_RUN_PATH='$ORIGIN/../libc'
In the future-version QPKG, I can create a libc folder inside the opt directory and place the libraries there and then the binaries should work from every path. Of course, if there is no libc folder, they should work as usual, looking for libraries in the system.

I tried with patchelf and it's working correctly with '$ORIGIN/../libc', at least for the binary files.
While preloading the libraries on 64-bit NAS gives me always this error:
[~] # LD_PRELOAD=/opt/lib/libmediaclient.so ls
ERROR: ld.so: object '/opt/lib/libmediaclient.so' from LD_PRELOAD cannot be preloaded: ignored.
index_default.htmlThe same on the 32-bit QNAP doesn't give any error:
[~] # LD_PRELOAD=/opt/lib/libmediaclient.so ls
index_default.htmlI cannot explain this behaviour, maybe it's due to the missing libraries too? We'll see!