Beiträge anzeigen

Diese Sektion erlaubt es ihnen alle Beiträge dieses Mitglieds zu sehen. Beachten sie, dass sie nur solche Beiträge sehen können, zu denen sie auch Zugriffsrechte haben.


Nachrichten - virtualdj

Seiten: [1]
1
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 ???

2
From the latest tests it seems that the libmediaclient.so from armsysv works correctly with the TVHeadend loader (i.e. the tuner is visible), while the harmsysvhf does not.

There's a side, effect, though: users get the famous ERROR: ld.so: object 'libmediaclient.so' from LD_PRELOAD cannot be preloaded: ignored. message on the commands run before the loader, which are the QNAP binaries that do not use the updated libraries (such as echo, find, etc.).

EDIT: I cannot replicate this situation in my ARM VM (neither the armv5 nor armv7) and the library always preloads correctly, without any messages. But I would like to fix this small glitch too, or either suppress the error message.

3
OK, I'm on the chat!

4
Hi, I cross-post here what I've written on the QNAP forum (sorry for that) because I think that you're not actively monitoring that discussion.

TVHeadend application introduced several additions in the latest versions and I'm not able to compile it anymore with my old ARM VM that is using an old glibc (see for example my pending support ticket).

So my TVHeadend QPKG 0.9.1.1 distribution package has been upgraded to 0.9.2 with the newer glibc but this unfortunately broke the Sundtek libmediaclient on ARM.
This does not happen with x86_64, but I didn't change the libc in that case of course.

I haven't an ARM NAS to try myself directly, but I was able to replicate the problem within the ARM VM.
This is what it prints with older glibc (QPKG 0.9.1.1 WORKING):
root@debian-armel:~/test/old# LD_PRELOAD=/root/test/libmediaclient.so ./tvh-loader --library-path . ./tvheadend --config . --abort
2018-04-21 16:32:45.157 [   INFO] main: Log started
2018-04-21 16:32:45.283 [   INFO] http: Starting HTTP server 0.0.0.0:9981
2018-04-21 16:32:45.450 [   INFO] htsp: Starting HTSP server 0.0.0.0:9982
.. CUT ..
2018-04-21 16:32:46.274 [ NOTICE] START: HTS Tvheadend version 4.3-1152~g2baa719-dirty started, running as PID:1410 UID:0 GID:0, CWD:/root/test/old CNF:/root/test/old
Aborted
And this is with newer glibc (QPKG 0.9.2 FAILING):
root@debian-armel:~/test# LD_PRELOAD=/root/test/libmediaclient.so ./tvh-loader --library-path . ./tvheadend --config . --abort
ERROR: ld.so: object '/root/test/libmediaclient.so' from LD_PRELOAD cannot be preloaded (cannot open shared object file): ignored.
2018-04-21 16:31:20.125 [   INFO] main: Log started
2018-04-21 16:31:20.257 [   INFO] http: Starting HTTP server 0.0.0.0:9981
2018-04-21 16:31:20.347 [   INFO] htsp: Starting HTSP server 0.0.0.0:9982
.. CUT ..
2018-04-21 16:31:21.391 [ NOTICE] START: HTS Tvheadend version 4.3-1236~g518d57bee started, running as PID:1379 UID:0 GID:0, CWD:/root/test CNF:/root/test
Aborted

The library libmediaclient.so is the latest downloaded from your armsysvhf archive and it's the same between the two simulations (older/newer glibc).
As you can see, with the newer glibc it fails to preload with the error cannot open shared object file. Here's the library:
root@debian-armel:~/test# md5sum /root/test/libmediaclient.so
f5efb30c9169122960bb836f2e4149c5  /root/test/libmediaclient.so
root@debian-armel:~/test# file /root/test/libmediaclient.so
/root/test/libmediaclient.so: ELF 32-bit LSB shared object, ARM, EABI5 version 1 (SYSV), dynamically linked, stripped

The linux dynamic loader (ld.so renamed here as "tvh-loader" for my convenience) EABI seems compatibile too:
root@debian-armel:~/test# file tvh-loader
tvh-loader: ELF 32-bit LSB shared object, ARM, EABI5 version 1 (SYSV), dynamically linked, BuildID[sha1]=4e62b2761d7a64fc51fd22235cff9e0ce5fccaa3, stripped

root@debian-armel:~/test# file old/tvh-loader
old/tvh-loader: ELF 32-bit LSB shared object, ARM, EABI5 version 1 (SYSV), dynamically linked, BuildID[sha1]=277b871de46b49b3a538abbdb5d1cc0adb5440ec, stripped
The version of libc.so.6 is obviously different:
root@debian-armel:~/test# ./libc.so.6 | grep "Compiled"
Compiled by GNU CC version 6.3.0 20170516.

root@debian-armel:~/test# ./old/libc.so.6 | grep "Compiled"
Compiled by GNU CC version 4.4.5.
Compiled on a Linux 2.6.32 system on 2011-01-23.

I've also tried prepending LD_DEBUG=libs but there are not significant differences, while with LD_DEBUG=files there's this:
root@debian-armel:~/test# LD_DEBUG=files LD_PRELOAD=/root/test/libmediaclient.so ./tvh-loader --library-path . ./tvheadend --config . --abort   
      1536:     file=./tvheadend [0];  generating link map
      1536:
      1536:     WARNING: Unsupported flag value(s) of 0x8000000 in DT_FLAGS_1.
      1536:       dynamic: 0xb6d0f84c  base: 0xb5751000   size: 0x0180b660
      1536:         entry: 0xb58410c4  phdr: 0xb5751034  phnum:         10
      1536:
      1536:
      1536:     file=/root/test/libmediaclient.so [0];  needed by ./tvheadend [0]
ERROR: ld.so: object '/root/test/libmediaclient.so' from LD_PRELOAD cannot be preloaded (cannot open shared object file): ignored.
      1536:
      1536:     file=libdvbcsa.so.1 [0];  needed by ./tvheadend [0]
      1536:     file=libdvbcsa.so.1 [0];  generating link map
      1536:       dynamic: 0xb574df08  base: 0xb572d000   size: 0x00021074
      1536:         entry: 0xb572db98  phdr: 0xb572d034  phnum:          6
      1536:
      1536:
      1536:     file=libssl.so.1.1 [0];  needed by ./tvheadend [0]
      1536:     file=libssl.so.1.1 [0];  generating link map
      1536:       dynamic: 0xb5728ee0  base: 0xb56cc000   size: 0x00060c7c
      1536:         entry: 0xb56da688  phdr: 0xb56cc034  phnum:          6
      1536:
      1536:
      .. CUT ..
     
root@debian-armel:~/test/old# LD_DEBUG=files LD_PRELOAD=/root/test/libmediaclient.so ./tvh-loader --library-path . ./tvheadend --config . --abort
      1566:     file=./tvheadend [0];  generating link map
      1566:       dynamic: 0xb6f0f270  base: 0xb638e000   size: 0x00bd8794
      1566:         entry: 0xb641c854  phdr: 0xb638e034  phnum:          9
      1566:
      1566:
      1566:     file=/root/test/libmediaclient.so [0];  needed by ./tvheadend [0]
      1566:     file=/root/test/libmediaclient.so [0];  generating link map
      1566:       dynamic: 0xb638b00c  base: 0xb6374000   size: 0x00017b68
      1566:         entry: 0xb63755b0  phdr: 0xb6374034  phnum:          5
      1566:
      1566:
      1566:     file=libssl.so.0.9.8 [0];  needed by ./tvheadend [0]
      1566:     file=libssl.so.0.9.8 [0];  generating link map
      1566:       dynamic: 0xb6370f4c  base: 0xb632a000   size: 0x00049cb8
      1566:         entry: 0xb6337d60  phdr: 0xb632a034  phnum:          5
      1566:
      1566:
      .. CUT ..

Have you got any suggestions on how to fix it? As I said, with the older glibc that preloads libmediaclient.so correctly I'm unable to compile the latest TVHeadend...  :(

5
Sundtek Streaming Server / Re:Sundtek Streaming Server (Englisch / English)
« am: September 06, 2017, 09:07:13 Nachmittag »
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.

6
Drivers / Re:QNAP 64-bit drivers development question
« am: August 25, 2015, 04:29:25 Nachmittag »
I will make a note on the download thread, then. Thanks.

7
Drivers / Re:QNAP 64-bit drivers development question
« am: August 25, 2015, 03:44:42 Nachmittag »
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).

8
Drivers / Re:QNAP 64-bit drivers development question
« am: Mai 05, 2015, 08:48:12 Nachmittag »
Hi Sundtek, have you got any news from the developer?

9
Drivers / Re:QNAP 64-bit drivers development question
« am: April 25, 2015, 05:47:41 Nachmittag »
Thanks, exporting LD_LIBRARY_PATH is always an hassle and I removed it from TVHeadend QPKG too.

10
Drivers / Re:QNAP 64-bit drivers development question
« am: April 25, 2015, 05:34:35 Nachmittag »
There are 2 versions of libmediaclient.so one is 32bit the other one has 64bit.
You can pull the specific drivers from our server as you might know:
http://sundtek.de/media/netinst/32bit/installer.tar.gz
http://sundtek.de/media/netinst/64bit/installer.tar.gz
That's what I just do, otherwise the 32bit libmediaclient.so would not run on the 64bit TVHeadend at all.
I'm just asking if you know why the 64bit spits out that message on every command (in the example, when running "ls").

I don't think that we can compile the drivers with a special path for the libraries because it would break the generic support of the driver, so the only way to get around that is to use LD_LIBRARY_PATH to the libraries which are missing.
Just for my info, why would it break the support if the binaries look for a folder which does not exists (because it's a subfolder of your installation path, "libc" in this case)?
Isn't "$ORIGIN" supported by all the platforms?

Aside of that we're also working on our own VCR software for the NAS systems the ETA will be around 3 months, first we are going to implement a player (ETA for the first beta should be within next month).
Cool! ;D

11
Drivers / QNAP 64-bit drivers development question
« am: April 25, 2015, 04:46:19 Nachmittag »
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.html
The same on the 32-bit QNAP doesn't give any error:
[~] # LD_PRELOAD=/opt/lib/libmediaclient.so ls
index_default.html
I cannot explain this behaviour, maybe it's due to the missing libraries too? We'll see!

Seiten: [1]