[Milhouse]

Not sure if anyone has pointed this out yet, but the new 30Aug2014 build of librtmp also doesn't work in OpenELEC Helix on x86, so it's not just an R-Pi (ie. architecture) issue - it's a platform issue.

Code:

OpenELEC:~/lib # head -6 /storage/xbmc.log
16:52:13 T:140493183813504  NOTICE: special://profile/ is mapped to: special://masterprofile/
16:52:13 T:140493183813504  NOTICE: -----------------------------------------------------------------------
16:52:13 T:140493183813504  NOTICE: Starting Kodi (14.0-ALPHA4 Git:247f4ae). Platform: Linux x86 64-bit
16:52:13 T:140493183813504  NOTICE: Using Release Kodi x64 build
16:52:13 T:140493183813504  NOTICE: Kodi compiled Sep  2 2014 by GCC 4.9.1 for Linux x86 64-bit version 3.16.1 (200705)
16:52:13 T:140493183813504  NOTICE: Running on OpenELEC (official) - Version: devel-20140902150354-r19159-g43bef62 5.0, kernel: Linux x86 64-bit version 3.16.1

OpenELEC:~/lib # ls -la
total 296
drwxr-xr-x    2 root     root          4096 Sep  4 17:57 .
drwxr-xr-x   24 root     root          4096 Sep  2 14:14 ..
lrwxrwxrwx    1 root     root            25 Aug 11  2013 librtmp.so -> /storage/lib/librtmp.so.0
-rwxr-xr-x    1 root     root        145083 Sep  4 17:56 librtmp.so.0

OpenELEC:~/lib # ldd librtmp.so.0
        linux-vdso.so.1 (0x00007fff5f3fd000)
        libssl.so.1.0.0 => not found
        libcrypto.so.1.0.0 => not found
        libz.so.1 => /usr/lib/libz.so.1 (0x00007f3f37618000)
        libm.so.6 => /lib/libm.so.6 (0x00007f3f37313000)
        libc.so.6 => /lib/libc.so.6 (0x00007f3f36f69000)
        /lib64/ld-linux-x86-64.so.2 (0x00007f3f3784b000)

The error when librtmp.so.0 is loaded on OpenELEC Helix x86:

Code:

17:53:04 T:140491324647168   ERROR: Unable to load librtmp.so.0, reason: libssl.so.1.0.0: cannot open shared object file: No such file or directory

However in a Gotham build of OpenELEC 4.0.7, there is no problem running the new librtmp:

Code:

OpenELEC:~/lib # head -6 /storage/xbmc.log
18:07:35 T:139922543662976  NOTICE: special://profile/ is mapped to: special://masterprofile/
18:07:35 T:139922543662976  NOTICE: -----------------------------------------------------------------------
18:07:35 T:139922543662976  NOTICE: Starting XBMC (13.1 Git:84725b0). Platform: x86 Linux 64-bit
18:07:35 T:139922543662976  NOTICE: Using Release XBMC x64 build, compiled Jul  9 2014 by GCC 4.9.0 for x86 Linux 64-bit 3.14.11
18:07:35 T:139922543662976  NOTICE: Running on Linux 64-bit (OpenELEC (official) - Version: 4.0.7, 3.14.11 x86_64)
18:07:35 T:139922543662976  NOTICE: Host CPU: Intel(R) Atom(TM) CPU D525 @ 1.80GHz, 4 cores available

OpenELEC:~/lib # ldd librtmp.so.0
./librtmp.so.0: /usr/lib/libssl.so.1.0.0: no version information available (required by ./librtmp.so.0)
./librtmp.so.0: /usr/lib/libcrypto.so.1.0.0: no version information available (required by ./librtmp.so.0)
        linux-vdso.so.1 (0x00007fff3ddff000)
        libssl.so.1.0.0 => /usr/lib/libssl.so.1.0.0 (0x00007fd97719d000)
        libcrypto.so.1.0.0 => /usr/lib/libcrypto.so.1.0.0 (0x00007fd976dd2000)
        libz.so.1 => /usr/lib/libz.so.1 (0x00007fd976dc0000)
        libm.so.6 => /lib/libm.so.6 (0x00007fd976aba000)
        libc.so.6 => /lib/libc.so.6 (0x00007fd976721000)
        libdl.so.2 => /lib/libdl.so.2 (0x00007fd97651d000)
        libgcc_s.so.1 => /usr/lib/libgcc_s.so.1 (0x00007fd976306000)
        /lib64/ld-linux-x86-64.so.2 (0x00007fd977622000)

This is the ldd output for the system /usr/lib/librtmp.so.0:

Code:

OpenELEC:~ # ldd /usr/lib/librtmp.so.0
        linux-vdso.so.1 (0x00007fffbe854000)
        libssl.so.27 => /usr/lib/libssl.so.27 (0x00007fd6438fe000)
        libcrypto.so.30 => /usr/lib/libcrypto.so.30 (0x00007fd64376d000)
        libz.so.1 => /usr/lib/libz.so.1 (0x00007fd64375b000)
        libc.so.6 => /lib/libc.so.6 (0x00007fd6433b0000)
        /lib64/ld-linux-x86-64.so.2 (0x00007fd64396c000)

The easiest solution would be to build with statically linked libssl/libcrypto. Building with dynamic libssl/libcrypto should be possible, as long as there is no hard dependency on OpenSSL. Building librtmp against libressl for OpenELEC Helix might be another option, though more work etc.

[Mabs]

Hi Mabs,
thank you for provide me your apk,it works fine but i can't hide the systembar,it's very annoying.

Just like the original one, remember? I only updated the librtmp...
You can give your feedback on SPMC in the correct topic and forum.

[Hustler]

(since 3.0) I was testing openElec and had Helix 4.1.7 on a Rpi and gave the librtmp file a shot and came back with the error

[Errno 2] No such file or directory: '/opt/xbmc-bcm/xbmc-bin/lib/xbmc/system/librtmp.so.0'**************

I then reverted back to OE 4.0.7 Official because I wanted the file and then got error code

:22:37 T:3058757632 ERROR: Unable to load libcurl.so.4, reason: /var/tmp/libhack/3rdparty/librtmp.so.0: invalid ELF header

Booted and scrolled through the menus and it crashed... Been in an endless loop since.
Strange thing is it seems to be looping in the second stage of the boot process.
I can still connect to it via .ssh
I had the original 4.0 backup I tried to no avail.

Back to the drawing board

[nickr]

4.1.7 is not helix

[Milhouse]

The first error looks like Kodi (I assume it's Kodi, I don't really recognise that error message format to be honest) is trying to use a Raspbmc path... a path that doesn't exist on OpenELEC.

As for your second problem, did you install the correct RPI librtmp.so.0 file? What librtmp.so file are you using (there have been a few test versions) as I've not seen either error before - I have seen Helix (not Gotham) fail to load libcurl due to the latest librtmp, but that's to do with libssl (or lack of).

Code:

0:27:55 T:140123844900608   DEBUG: SECTION:LoadDLL(libcurl.so.4)
0:27:55 T:140123844900608   DEBUG: Loading: libcurl.so.4
0:27:55 T:140123844900608   ERROR: Unable to load libcurl.so.4, reason: libssl.so.1.0.0: cannot open shared object file: No such file or directory
0:27:55 T:140123844900608   DEBUG: Dll libcurl.so.4 was not found in path

Your ELF error suggests you've installed librtmp for a different architecture (x86?)

Edit: And yes, nickr is correct - if you want Helix you need a nightly based on OpenELEC master (or one of my test builds).

[Hustler]

The first error looks like Kodi (I assume it's Kodi, I don't really recognise that error message format to be honest) is trying to use a Raspbmc path... a path that doesn't exist on OpenELEC.

As for your second problem, did you install the correct RPI librtmp.so.0 file? What librtmp.so file are you using (there have been a few test versions) as I've not seen either error before - I have seen Helix (not Gotham) fail to load libcurl due to the latest librtmp, but that's to do with libssl (or lack of).

Code:

0:27:55 T:140123844900608   DEBUG: SECTION:LoadDLL(libcurl.so.4)
0:27:55 T:140123844900608   DEBUG: Loading: libcurl.so.4
0:27:55 T:140123844900608   ERROR: Unable to load libcurl.so.4, reason: libssl.so.1.0.0: cannot open shared object file: No such file or directory
0:27:55 T:140123844900608   DEBUG: Dll libcurl.so.4 was not found in path

Your ELF error suggests you've installed librtmp for a different architecture (x86?)

Edit: And yes, nickr is correct - if you want Helix you need a nightly based on OpenELEC master (or one of my test builds).

Ahhhhh I'm sorry I was assuming it was helix. It was your testbuild. I have the Leopod script that I always used for
Officail, Rbej and your builds. It is possible I have had the wrong Lib as I got it elsewhere.
My first attempt at updating this.
Sorry for the confusion

[Milhouse]

My builds /are/ Helix, though it would help if you used my build numbers (#0905 etc.) to avoid any further confusion - the build number is displayed on the boot screen, and when you run the command "lsb_release".

I still don't recognise your first error though, are you seeing that in your xbmc.log? I have no idea why OpenELEC would be attempting to reference a Raspbmc path, unless it had somehow been hard coded into the library (very unlikely) or incorrectly added to LD_LIBRARY_PATH (much more likely).... Have you been following a librtmp installation guide meant for Raspbmc?

[Hustler]

NO One of the forums has a 1 click fix in the maintenance tool and it did not specify what it was other than
for the Rpi.
The other I had done with ssh

[Soeiro02]

Hello friends, I seem to lose traction on this thread...did you reach any conclusion regarding the Raspbmc's reboots?

I can help testing if you need.

[RedPenguin]

Hello friends, I seem to lose traction on this thread...did you reach any conclusion regarding the Raspbmc's reboots?

I can help testing if you need.

I am still working on the issue. I already tried 3 test files, but seem to be getting no where. Got busy and am still somewhat busy, so it's taking longer than I would have liked.

It just seems RaspBMC hates any file I give it for the most part....

[Soeiro02]

Thanks for the update, RP.

If you need non-developer help, just ping me.

[RedPenguin]

Something very strange is going on here.

I for testing, just did a 100% redo from scratch on my RasPi using Release not Experimental.

I then placed in my RasPi build from MediaFire (not from the 3 test files).

It not only did no crash XBMC, but also played a mip s which was just fixed, so I know it's using my build.

All I can figure is there must be something broken on some folks builds of RaspBMC that is out of my control.

[Soeiro02]

RP, I can assure you that my faulty Raspi was using the latest official Raspbmc build, but after the sd card preparation, it was the system that connected to Raspbmc's server and downloaded the build, so I have reasons to believe that it downloads the latest stable one.

What I cannot assure is if this downloaded build has issues, but that part we cannot control, of course.

[RedPenguin]

RP, I can assure you that my faulty Raspi was using the latest official Raspbmc build, but after the sd card preparation, it was the system that connected to Raspbmc's server and downloaded the build, so I have reasons to believe that it downloads the latest stable one.

What I cannot assure is if this downloaded build has issues, but that part we cannot control, of course.

I know.

What I mean is, I think there is something strange between RaspBMC builds somewhere.

I mean you would think every single install would have the bug.

I'm wondering if some were left with a buggy XBMC or something.

EDIT: Only thing I can think of right now, and ns if you would be willing, if not I understand, would be if you allowed Remote Access (SSH) to your Pi so I can see if there if anything strange vs mine.

My issue is, I can't seem to break mine to find the actual cause.

[Soeiro02]

RP, the least I can do is help you to help me. I have no problem in granting you remote access, if it's technically possible.

Thing is, I'm currently on vacation and away from home until next weekend.

If it's ok with you, I'll pm you when I'm ready.

Thanks again.