[hardyt]

Hi there, I just got some Hue lights and was excited to try out this add-on, but I'm getting a "Can't Load DLL" error when I try to run it.

I'm running Kodi Isengard on Ubuntu. Is there a dependency that I need to install?

Thanks,

--
Francis

It's probably a 32-bit vs 64-bit issue. I only had 32-bit Ubuntu. Is your 64-bit?

[hardyt]

Hi,

I tried this addon today, and could not make it working.

1- I installed it (32bit ubuntu/win version)
2 - I played a song
3 - I selected WaveforHue as vizualisation
4 - I configured the addon (IP and Bulbs numbers)
5 - I played the next song and ran fast to push the bridge button (less than 10 seconds)
6 - I played the next song...

Nothing happened.

But I noticed that with this visualization enabled, my music can't be played smoothly.... like if the addon was pushing my CPU to his limits. My computer's power is good, so this problem is strange.

My computer is running kubuntu 15.04 64bit. Should it be 32 bit ? Is there a 64 bit version of this addon ?

thank you for your help.

?? FOR A USER FRIENDLY PROCESS : it would be a good idea to show a notification for the linking process with the bridge. The notification should tell us that the linking is needed, and time left before the end. Another notification should show the success or the fail of the pairing process.

The version I built for Ubuntu was 32-bit. It's also possible your bridge is not responding well enough. I had a problem similar to yours and swapping the ethernet cable to the bridge fixed it. Do the lights change color at all?

[hardyt]

https://github.com/notspiff/visualization.waveforhue

Thanks ironic_monkey. I used this today! Branched to https://github.com/hardyt/visualization.wavforhue.

Everyone, Lots of updates to visualization.wavforhue. Check the main post.

[hardyt]

https://github.com/notspiff/visualization.waveforhue

ironic_monkey, with this cmake version Ubuntu generic x86_64 won't work due to something going wrong with the curl library. This is the error:

Code:

/usr/lib/x86_64-linux-gnu/libcurl.so.4: version `CURL_OPENSSL_4' not found

From what I can find on the web people have to build the binary themselves or curl needs to be statically linked. But my intution is that Kodi knows how to use curl and there's an easy way to modify the CMakeLists.txt or the source code to fix this. Any guidance? Thanks!

[ironic_monkey]

i'm taking an educated guess but i think the problem is that there are several versions of curl available in the ubuntu repositories. one version using openssl and one version using gnutls. on your build box you seem to have had the first one (libcurl4-openssl(-dev)), while on the box of whoever is executing the addon there is the other one.

this is why you don't distribute binaries in ubuntu in raw/zip form, but as .deb files. they will explicitly list which version of packages are required (if packaging is done correctly).

[hardyt]

I've tried both libcurl4-openssl-dev and libcurl4-gnutls-dev (my box defaults to dev..). Both give that same error when Kodi runs. But Kodi's use of curl is unaffected. I don't even use https.

Can you point out how to use curl the same way Kodi does? It's very confusing to me. I looked at the sources for days last year and most of the day yesterday and I still don't get it. I see the main source file is DllLibCurl.. but I'm not sure how to include it and use it's functions.

[ironic_monkey]

kodi doesn't link to curl at compile time. rather it dlopen's the library on runtime when needed. DllLibCurl.h is the wrapper for using it in such a manner. doing that in your add-on entails quite a lot of code, and i really do not recommend even attempting it (you'd pull in large parts of the kodi codebase..). also it wouldn't solve your problem in any way.

a small explanation of debian packaging and unix library handling seems in order.

packages in debian is split in runtime and development packages. in particular, the -dev packages holds the headers, and certain important symlinks related to how linux library versioning works. these are files only needed during development, none of this should be needed during runtime (i.e. for users).

consider this output;

Code:

ls /usr/lib/x86_64-linux-gnu/libcurl*so* -l
lrwxrwxrwx 1 root root     23 Jan 26 21:05 /usr/lib/x86_64-linux-gnu/libcurl-gnutls.so -> libcurl-gnutls.so.4.3.0
lrwxrwxrwx 1 root root     19 Jan 26 21:05 /usr/lib/x86_64-linux-gnu/libcurl-gnutls.so.3 -> libcurl-gnutls.so.4
lrwxrwxrwx 1 root root     23 Jan 26 21:05 /usr/lib/x86_64-linux-gnu/libcurl-gnutls.so.4 -> libcurl-gnutls.so.4.3.0
-rw-r--r-- 1 root root 401512 Jan 26 21:05 /usr/lib/x86_64-linux-gnu/libcurl-gnutls.so.4.3.0
lrwxrwxrwx 1 root root     17 Jan 26 21:05 /usr/lib/x86_64-linux-gnu/libcurl.so -> libcurl-gnutls.so
lrwxrwxrwx 1 root root     12 Jan 26 21:05 /usr/lib/x86_64-linux-gnu/libcurl.so.3 -> libcurl.so.4
lrwxrwxrwx 1 root root     16 Jan 26 21:05 /usr/lib/x86_64-linux-gnu/libcurl.so.4 -> libcurl.so.4.3.0
-rw-r--r-- 1 root root 422696 Jan 26 21:05 /usr/lib/x86_64-linux-gnu/libcurl.so.4.3.0

this is my system when i have libcurl4-gnutls-dev installed. note how the libcurl.so symlink points to libcurl-gnutls.so (which again is a symlink to libcurl-gnutls.so.4.3.0).

and this is my system when i have libcurl4-openssl-dev installed

Code:

ls /usr/lib/x86_64-linux-gnu/libcurl*so* -l
lrwxrwxrwx 1 root root     19 Jan 26 21:05 /usr/lib/x86_64-linux-gnu/libcurl-gnutls.so.3 -> libcurl-gnutls.so.4
lrwxrwxrwx 1 root root     23 Jan 26 21:05 /usr/lib/x86_64-linux-gnu/libcurl-gnutls.so.4 -> libcurl-gnutls.so.4.3.0
-rw-r--r-- 1 root root 401512 Jan 26 21:05 /usr/lib/x86_64-linux-gnu/libcurl-gnutls.so.4.3.0
lrwxrwxrwx 1 root root     16 Jan 26 21:05 /usr/lib/x86_64-linux-gnu/libcurl.so -> libcurl.so.4.3.0
lrwxrwxrwx 1 root root     12 Jan 26 21:05 /usr/lib/x86_64-linux-gnu/libcurl.so.3 -> libcurl.so.4
lrwxrwxrwx 1 root root     16 Jan 26 21:05 /usr/lib/x86_64-linux-gnu/libcurl.so.4 -> libcurl.so.4.3.0
-rw-r--r-- 1 root root 422696 Jan 26 21:05 /usr/lib/x86_64-linux-gnu/libcurl.so.4.3.0

now libcurl.so points to libcurl.so.4.3.0 (the openssl variant).

since these packages hold the same files, they are mutually exclusive. you will notice that if you install one, the other is removed (if it was already installed).

now, why is this important? because that symlink (libcurl.so) is the thing used when your application links the curl library (i.e. when you add -lcurl in the Makefile).
however, the first symlink is resolved. so in the resulting binary, the shared library it points to will be recorded - namely libcurl.so.4 (if i have the libcurl4-openssl-dev package installed),
or libcurl-gnutls.so.4 (if i have the gnutls version installed).

why all this explaining? to point out that which -dev package you have installed will affect which library your add-on links to. and that for this reason binaries are NOT portable across distros, nor across versions of the same distro. you cannot build on 14.04 and expect to run on anything else.

show me the output of

Code:

ldd <binary>

on the box where it doesn't run please. i just built on my box, it locks for a long time on curl timeout in the addon but it loads and initializes fine.

my suspicion is that your kodi is using one curl and the addon the other.

[hardyt]

I figured out what I was doing wrong. I was using the OpenELEC build system to try and build an addon for Ubuntu. Whoops. I used cmake directly and it works. Thank you for the education about curl!

[hardyt]

Now on to binaries for other architectures and OS's. Is it possible to build this addon for other architectures and os's on Ubuntu? Or is it easier if I just set up development boxes for each major environment (Android, Raspberry Pi, etc)?

[ironic_monkey]

there's a buildsystem capable of building addons for all platforms in project/cmake/addons.

this can be used to crosscompile for android, rpi etc through tools/depends

[hardyt]

Ok, thank you. I read through that.

So for platform "x", my understanding is I need clone the kodi repository, cmake kodi using "-DCORE_SYSTEM_NAME=x", and then cmake my addon using "-DCORE_SYSTEM_NAME=x". Is that the right/most efficient workflow? How do I build for different architectures, like x86 Ubuntu vs 64-bit Ubuntu?

Apparently there's pages and pages about this on the forum... busy reading..

[ironic_monkey]

read the depends README. you point depends to the relevant toolchain, and build addons using tools/depends/target/binary-addons

note that this buildsystem is intended for embedded platforms. all dependencies will be built and linked statically. it's not how i'd recommend doing ubuntu builds. for ubuntu builds, use deb packaging.
pbuilder (or launchpad).

[ironic_monkey]

i just did a run of the latter. using https://github.com/notspiff/visualizatio...i_packaged i got debs through pbuilder hassle-free (as hassle free as it can be when having dependencies in a ppa).

- remove binaries from git. git is NOT for hosting binaries, it's for source code. use the 'release' page on github for those.
- since i built against 15.2 and 15.2 did not support addon.xml.in i had to add a manually generated addon.xml (just because i went with 15)
- update packaging to reflect dependencies

[ironic_monkey]

Code:

1. Install pbuilder.
  sudo apt-get install pbuilder

2. setup the chroot's you want. e.g.
sudo pbuilder --create --distribution trusty --architecture amd64 --basetgz /var/cache/pbuilder/trusty-amd64.tgz
sudo pbuilder --create --distribution trusty --architecture i386 --basetgz /var/cache/pbuilder/trusty-i386.tgz

3. for each chroot
  -sudo pbuilder login --save-after-login

in the chroot, do
echo "deb http://ppa.launchpad.net/team-xbmc/ppa/ubuntu trusty main" >>  /etc/apt/sources.list
apt-key adv --keyserver keyserver.ubuntu.com --recv-keys 91E7EE5E

replace trusty with relevant code name of distro version

4. go to source of add-on and create orig tgz
git archive --prefix kodi-visualization-wavforhue_1.0.0/ -o ../kodi-visualization-wavforhue_1.0.0.orig.tar.gz <name of branch to export>

5. type pdebuild --basetgz <chroot to use>

debs are spit out in /var/cache/pbuilder/result

[hardyt]

I'd love to play with this, but I get a 'wrong ELF class: ELFCLASS64' for WaveforHue.vis when trying with i686 Linux.

Any chance of a 32 bit compile?

I've built a 32-bit binary for Ubuntu. You can give that a shot. It worked for me on Ubuntu 14.04. Let me know if it works for you. The binaries are linked in post #1.