Unable to start addon about pvr.hts HOT 44 CLOSED

Thanks for the report but this is a dev only space.

Please post at http://forum.kodi.tv/forumdisplay.php?fid=168

from pvr.hts.

Might as well use this issue tracker, it's a PITA to follow bug reports on the forum.

from pvr.hts.

Guess it makes sense. Wrongly assumed things would work as kodi-core.

from pvr.hts.

Opened a bug via kodi trac and were said that it has been decided to use bug tracking here????
I'm confused

from pvr.hts.

That's right, bugs in this addon should be reported here from now on.

from pvr.hts.

@lwis your hostname is at least incorrect, can you fix that and get a new debug log if you still have problems?

from pvr.hts.

@Jalle19 Hostname was purposely redacted. If I can provide any further information, please let me know. Looking at the forums it seems like I'm not alone with this problem.

Also it's probably worth noting that I'm running xbmcbuntu.

from pvr.hts.

/usr/lib/kodi/addons/pvr.hts/pvr.hts.so: undefined symbol: hts_sha1_size

Looks, your addon is linked dynamically against libhts and that this shared lib is present on your system, but does not provide the required symbol. This is strange, as libhts is supposed to be linked statically. https://github.com/kodi-pvr/pvr.hts/blob/master/lib/libhts/CMakeLists.txt#L24 Did you build the addon that produced the above error by yourself and if so, how? If not, where do you got it from?

Could you give us the output of "ldd -r /usr/lib/kodi/addons/pvr.hts/pvr.hts.so", please.

from pvr.hts.

@ksooo Add-on was always obtained from the launchpad PPA.

linux-vdso.so.1 =>  (0x00007fff6e7f6000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007faef24e0000)
libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007faef21d1000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007faef1fb9000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007faef1bf5000)
/lib64/ld-linux-x86-64.so.2 (0x00007faef2944000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007faef18ef000)

undefined symbol: hts_sha1_size (/usr/lib/kodi/addons/pvr.hts/pvr.hts.so)
undefined symbol: htsmsg_get_map (/usr/lib/kodi/addons/pvr.hts/pvr.hts.so)
undefined symbol: hts_sha1_init (/usr/lib/kodi/addons/pvr.hts/pvr.hts.so)
undefined symbol: htsmsg_binary_serialize (/usr/lib/kodi/addons/pvr.hts/pvr.hts.so)
undefined symbol: htsmsg_get_s64 (/usr/lib/kodi/addons/pvr.hts/pvr.hts.so)
undefined symbol: htsmsg_binary_deserialize (/usr/lib/kodi/addons/pvr.hts/pvr.hts.so)
undefined symbol: htsmsg_get_str (/usr/lib/kodi/addons/pvr.hts/pvr.hts.so)
undefined symbol: htsmsg_add_u32 (/usr/lib/kodi/addons/pvr.hts/pvr.hts.so)
undefined symbol: htsmsg_get_list (/usr/lib/kodi/addons/pvr.hts/pvr.hts.so)
undefined symbol: hts_sha1_update (/usr/lib/kodi/addons/pvr.hts/pvr.hts.so)
undefined symbol: htsmsg_add_str (/usr/lib/kodi/addons/pvr.hts/pvr.hts.so)
undefined symbol: dlsym (/usr/lib/kodi/addons/pvr.hts/pvr.hts.so)
undefined symbol: htsmsg_add_bin (/usr/lib/kodi/addons/pvr.hts/pvr.hts.so)
undefined symbol: hts_sha1_final (/usr/lib/kodi/addons/pvr.hts/pvr.hts.so)
undefined symbol: htsmsg_add_s32 (/usr/lib/kodi/addons/pvr.hts/pvr.hts.so)
undefined symbol: dlerror (/usr/lib/kodi/addons/pvr.hts/pvr.hts.so)
undefined symbol: htsmsg_destroy (/usr/lib/kodi/addons/pvr.hts/pvr.hts.so)
undefined symbol: htsmsg_get_u32_or_default (/usr/lib/kodi/addons/pvr.hts/pvr.hts.so)
undefined symbol: htsmsg_create_map (/usr/lib/kodi/addons/pvr.hts/pvr.hts.so)
undefined symbol: htsmsg_get_u32 (/usr/lib/kodi/addons/pvr.hts/pvr.hts.so)
undefined symbol: htsmsg_add_s64 (/usr/lib/kodi/addons/pvr.hts/pvr.hts.so)
undefined symbol: dlopen (/usr/lib/kodi/addons/pvr.hts/pvr.hts.so)
undefined symbol: htsmsg_get_bin (/usr/lib/kodi/addons/pvr.hts/pvr.hts.so)
undefined symbol: dlclose (/usr/lib/kodi/addons/pvr.hts/pvr.hts.so)

Edit: bastard backtick fencing isn't working.

from pvr.hts.

Yeah, it's what I thought. Blame the packagers.

They have to either link pvr.hts.so statically against libhts (like the always did in the past, I think) or to build and deliver libhts.so together with pvr.hts.so

Please file a bug against those guys. Whoever they are... :-/

Btw: the problem reported in the forum was different.

from pvr.hts.

@ksooo ah, okay. Thanks for taking a look for me, where would be the best place for me to raise an issue? (I don't even know where to start)

from pvr.hts.

"those guys" are you ;) https://github.com/kodi-pvr/pvr.hts/tree/master/debian

from pvr.hts.

ok, just checked our ubuntu package and its fine:
/usr/lib/kodi/addons/pvr.hts$ ldd pvr.hts.so.2.1.6
linux-vdso.so.1 => (0x00007ffe21ff6000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f3ef81d8000)
libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f3ef7ec9000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f3ef7cb1000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f3ef78ec000)
/lib64/ld-linux-x86-64.so.2 (0x00007f3ef864c000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f3ef75e6000)

from pvr.hts.

Then we have the thing that cannot be? @iwis uses our packages, which are okay, but obviously the packages he uses are not okay? Clueless...

from pvr.hts.

I just tried purging the package in fear that something had broken on install, but it's still borked.

from pvr.hts.

@wsnipex hehe, did not known about the Deboan packaging we are doing, sorry. Thanks for pointing that out.

from pvr.hts.

@lwis, please:
apt-cache policy kodi-pvr-hts

Note that the only package I tried is current master from the nightly ppa: https://launchpad.net/~team-xbmc/+archive/ubuntu/xbmc-nightly

from pvr.hts.

@wsnipex

kodi-pvr-hts:
  Installed: 2.1.6-1~utopic
  Candidate: 2.1.6-1~utopic
  Version table:
 *** 2.1.6-1~utopic 0
        500 http://ppa.launchpad.net/team-xbmc/xbmc-nightly/ubuntu/ utopic/main amd64 Packages
        100 /var/lib/dpkg/status

from pvr.hts.

no idea..
wuff@uboook:~$ readelf -a /usr/lib/kodi/addons/pvr.hts/pvr.hts.so | grep hts
0x000000000000000e (SONAME) Library soname: [pvr.hts.so.15.0]
112: 000000000001ba00 45 FUNC GLOBAL DEFAULT 11 htsmsg_create_map
149: 000000000001ba80 110 FUNC GLOBAL DEFAULT 11 htsmsg_delete_field
153: 0000000000026ff4 4 OBJECT GLOBAL DEFAULT 13 hts_sha1_size
176: 000000000001c740 120 FUNC GLOBAL DEFAULT 11 htsmsg_get_bin
177: 0000000000021730 25 FUNC GLOBAL DEFAULT 11 htsmsg_add_s32
209: 000000000001e4d0 174 FUNC GLOBAL DEFAULT 11 htsmsg_get_float
217: 0000000000021440 60 FUNC GLOBAL DEFAULT 11 htsmsg_add_msg_extname
220: 000000000001e4a0 43 FUNC GLOBAL DEFAULT 11 hts_sha1_init
236: 000000000001e280 210 FUNC GLOBAL DEFAULT 11 hts_sha1_update
238: 000000000001bb60 131 FUNC GLOBAL DEFAULT 11 htsmsg_binary_serialize
239: 000000000001a4c0 85 FUNC GLOBAL DEFAULT 11 htsmsg_get_list
243: 000000000001a580 234 FUNC GLOBAL DEFAULT 11 htsmsg_get_map_multi
244: 000000000001eaa0 63 FUNC GLOBAL DEFAULT 11 htsmsg_detach_submsg
245: 00000000000214c0 42 FUNC GLOBAL DEFAULT 11 htsmsg_add_binptr
246: 000000000001b9d0 45 FUNC GLOBAL DEFAULT 11 htsmsg_create_list
267: 0000000000021770 26 FUNC GLOBAL DEFAULT 11 htsmsg_add_u32
268: 000000000001eae0 41 FUNC GLOBAL DEFAULT 11 htsmsg_add_float
279: 000000000001c6d0 102 FUNC GLOBAL DEFAULT 11 htsmsg_field_get_string
280: 000000000001eb10 58 FUNC GLOBAL DEFAULT 11 htsmsg_copy
302: 0000000000021750 25 FUNC GLOBAL DEFAULT 11 htsmsg_add_s64
303: 000000000001d470 63 FUNC GLOBAL DEFAULT 11 htsmsg_get_s32
304: 0000000000021480 63 FUNC GLOBAL DEFAULT 11 htsmsg_add_msg
305: 000000000001baf0 110 FUNC GLOBAL DEFAULT 11 htsmsg_field_add
312: 0000000000021530 46 FUNC GLOBAL DEFAULT 11 htsmsg_add_str
335: 000000000001e360 319 FUNC GLOBAL DEFAULT 11 hts_sha1_final
340: 000000000001e580 368 FUNC GLOBAL DEFAULT 11 htsmsg_print
357: 000000000001a520 85 FUNC GLOBAL DEFAULT 11 htsmsg_get_map
362: 000000000001c7c0 40 FUNC GLOBAL DEFAULT 11 htsmsg_get_u32_or_default
375: 00000000000214f0 62 FUNC GLOBAL DEFAULT 11 htsmsg_add_bin
393: 00000000000207d0 55 FUNC GLOBAL DEFAULT 11 htsmsg_get_u32
395: 000000000001b530 87 FUNC GLOBAL DEFAULT 11 htsmsg_destroy
413: 000000000001ba30 76 FUNC GLOBAL DEFAULT 11 htsmsg_binary_deserialize
424: 0000000000020710 178 FUNC GLOBAL DEFAULT 11 htsmsg_get_s64
429: 0000000000022f40 78 FUNC GLOBAL DEFAULT 11 htsmsg_get_str

from pvr.hts.

http://pastebin.com/Ux9fdf0j

from pvr.hts.

@lwis please use pastebin for logs etc.

from pvr.hts.

mind showing what command you use exactly to produce that?

from pvr.hts.

readelf -a /usr/lib/kodi/addons/pvr.hts/pvr.hts.so | grep hts same as what you executed.

from pvr.hts.

well, I just purged and redownloaded kodi-pvr-hts and readelf still shows all symbols just fine.
I can't runtime test it though. Can anyone else try the ppa package?

from pvr.hts.

Fresh install, can't runtime test it.

http://pastebin.com/ffTBCnVJ

from pvr.hts.

So my readelf output looks like @hudokkow's, but he's unable to test.

from pvr.hts.

Did a runtime check with latest nightly build on Ubuntu 14.04 (x86_64). No problem. Works just fine.

readelf output ksooo, wsnipex:
153: 0000000000026ff4 4 OBJECT GLOBAL DEFAULT 13 hts_sha1_size
readelf output Iwis, huddokow:
33: 0000000000000000 0 NOTYPE GLOBAL DEFAULT UND hts_sha1_size

I'm not an expert on this, but there is a difference, right?

4 vs. 0 => size of the symbol
OBJECT vs. NOTYPE => symbol type
13 vs. UND => The section number the symbol is in.

There is something wrong with the shared lib of Iwis and huddokow... but as I said I'm not an expert an elf and linker stuff, sorry.

from pvr.hts.

I just finished rebuilding everything from scratch, using external tree build for kodiplatform and pvr.hts and it does not load for a diffrenet reason whereas using the fernetmenta provided script to install inside kodi and make it installed when installed via kodi install it works. The reason being that when specifying no install dir to kodiplatform cmake, it install the library in /usr/local/lib/x86_64-linux-gnu/libkodiplatform.so.15.0 but that the dynamic linker only search in /usr/local/lib on debian NOT /usr/local/lib/x86_64-linux-gnu. kinker does search in /usr/lib/x86_64-linux-gnu.

Puting the library in /usr/local/lib and rereunning ldconfig make the pvr addon work.

SECTION:LoadDLL(/usr/local/lib/kodi/addons/pvr.hts/pvr.hts.so)
18:36:47 T:140289175963392 DEBUG: Loading: /usr/local/lib/kodi/addons/pvr.hts/pvr.hts.so
18:36:47 T:140289175963392 ERROR: Unable to load /usr/local/lib/kodi/addons/pvr.hts/pvr.hts.so, reason: libkodiplatform.so.15.0: cannot open shared object file: No such file or directory
18:36:47 T:140289175963392 INFO: Called Add-on status handler for '4' of clientName:Tvheadend HTSP Client, clientID:pvr.hts (same Thread=no)
18:36:47 T:140289175963392 WARNING: UpdateAndInitialiseClients - failed to create add-on Tvheadend HTSP Client, status = 6
18:36:47 T:140289175963392 WARNING: UpdateAndInitialiseClients - failed to load the dll for add-on Tvheadend HTSP Client, disabling it
18:36:47 T:140289895589632 NOTICE: Thread AddonStatus pvr.hts start, auto delete: true

/usr/local$ find . -name libkodiplatform.so.15.0
find: "./lost+found": Permission non accordée
./lib/x86_64-linux-gnu/libkodiplatform.so.15.0

from pvr.hts.

@EricV the problem you describe is unrelated to the problem @iwis has, although the effect is the same.

@iwis seems to have a broken pvr.hts.so. (somehow not built correctly)

Your problem is a broken installation => reason: libkodiplatform.so.15.0: cannot open shared object file: No such file or directory. I do not understand what exactly you did (build and install) but the result is a broken installation as a shared library cannot be found. I cannot help here because I have no knowledge about the build and install procedure you took.

I use OpenELEC as platform (everything built myself) and sometimes Ubuntu for testing (where I use the official Kodi PPA).

from pvr.hts.

@ksooo . I know the problem is not the same I even wrote it myself. Result is indeed the same and the installation is broken because the kodiplatorm installation is broken due to incorrect installation place by default. But it does affect your plugging. And please read the post entirely. The reason and the solution is mentioned. I opened a bug report to kodi trac for it. But other may experience it and the goal is just to pass the info.

from pvr.hts.

@EricV Well, sure pvr.hts is affected, and yes, I red your entire posting. But as you wrote it is a problem with kodiplatform build/installation. My point was that I cannot help here because I simply have no knowledge about that area of kodi. Maybe @FernetMenta can help?

from pvr.hts.

@EricV its up to you to pass the correct CMAKE_INSTALL_PREFIX when building.
cmake -DCMAKE_INSTALL_PREFIX=/usr

from pvr.hts.

@wsnipex Wrong. By default all the rest in installed in /usr/local. I install in /usr only finished packages... And passing /usr/local would result in same error.

@ksooo I fixed the problem by putting le libraries at the correct location for debian /usr/local/lib. Problem is that the build system for kodiplatform is making wrong assumption for debian (dunno for Ubuntu but probably also).

from pvr.hts.

@EricV xbmc/kodi-platform@48bdd98 should fix this, right?

from pvr.hts.

No time to test it just yet but reading the diff, it indeed fixes the root cause: multiarch install should only be used if prefix=/usr

Edited : it indeed fixes the bug. Thanks for support.

from pvr.hts.

I can test when the next nightly is built.

On 23 March 2015 at 09:48, EricV [email protected] wrote:

No time to test it just yet but reading the diff, it indeed fixes the root
cause: multiarch install should only be used if prefix=/usr

—
Reply to this email directly or view it on GitHub
#18 (comment).

from pvr.hts.

@iwis sure, but I think this will not fix your issue as it has a different root cause, I'm afraid.

from pvr.hts.

@EricV you're welcome.

from pvr.hts.

@ksooo NB: the fix is correct but incomplete because the kodiplatform install script also lacks a call to ldconfig after library install (this is done when installing via packages by package installation scripts). Even if installed at the correct location pwr.hts still fails to load. Running ldconfig corrects the problem.

from pvr.hts.

feel free to build a package, we even ship proper debian packaging. We're not going to add ldconfig to our code.

from pvr.hts.

@wsnipex I will use packaging when it will be proposed by debian itself that is not tomorrow as you surely know ffmpeg being not even back in. For my understanding what is the problem of adding a ldconfig at install time for kodiplatform (yes the ldconfig suggestion is not for this package why should it be?)

from pvr.hts.

What would be the best course of action for me to get the nightlies working again? As I'm under the impression this is an edge case.

from pvr.hts.

mind giving http://members.a1.net/wsnipex/kodi-pvr-hts_2.1.6-2~utopic_amd64.deb a try?
It seems there is a bug in binutils in utopic that breaks LTO linking.

from pvr.hts.

That seems to have fixed it, thanks!
On 29 Mar 2015 10:59 am, "Wolfgang Schupp" [email protected] wrote:

mind giving
http://members.a1.net/wsnipex/kodi-pvr-hts_2.1.6-2~utopic_amd64.deb a try?
It seems there is a bug in binutils in utopic that breaks LTO linking.

—
Reply to this email directly or view it on GitHub
#18 (comment).

from pvr.hts.