Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[designmule]

Hi everyone

I recently updated my pi's to JRiver 25 and everything went fine. When I updated my Allo Sparky JRiver starts to open and then crashes. Starting it via command line produces the same result but returns the message "Illegal Instruction". I then uninstalled JRiver 25 and reinstalled JRiver 24. It runs fine and surprisingly retained all of my setting from before. I uninstalled it following the guides here on Interact. So I don't know if that might be causing an issue.

Any suggestions?

Thanks for the help
Matt

[Hendrik]

Thats an ARM system, right?
I haven't heard of any changes in that area how we build stuff.

Anything particular you are doing when it crashes? Or simply running it, doing nothing at all otherwise?

[designmule]

It is an arm system. ARM Cortex A9 Quad Core Processor at 1.1GHz.

I only use the device for music playback so other than the VNC service nothing is running and I am only attempting to start JRiver. I''m running DietPi (which I use on the pi's as well). I noticed that the version of JRiver was 25.0.50

My googling led me to think that it might be processor related as well. The DietPi installation page indicates that GPU features are not enabled if that matters.

[bob]

It is an arm system. ARM Cortex A9 Quad Core Processor at 1.1GHz.

I only use the device for music playback so other than the VNC service nothing is running and I am only attempting to start JRiver. I''m running DietPi (which I use on the pi's as well). I noticed that the version of JRiver was 25.0.50

My googling led me to think that it might be processor related as well. The DietPi installation page indicates that GPU features are not enabled if that matters.

I don't think that should matter but you can try running it under gdb and upon the crash you might get more info. The symbols aren't there but it will probably give a general stack trace.

gdb mediacenter25
run
when it dies
bt full

thanks.

[designmule]

So from terminal I first entered gdb mediacenter25 and it returned gdb license info, etc. then returned "Reading symbols from mediacenter25...(no debugging symbols found)...done.

The with gdb still open in the terminal I attempted to start medicenter 25 which crashed as it has been.

I then typed bt full in the terminal and gdb returned No stack.

I've never used gdb before so I've laid out my actions just in case I made a mistake.

Thanks for the help
Matt

[bob]

So from terminal I first entered gdb mediacenter25 and it returned gdb license info, etc. then returned "Reading symbols from mediacenter25...(no debugging symbols found)...done.

The with gdb still open in the terminal I attempted to start medicenter 25 which crashed as it has been.

I then typed bt full in the terminal and gdb returned No stack.

I've never used gdb before so I've laid out my actions just in case I made a mistake.

Thanks for the help
Matt

That's correct. Not sure why there is not a trace.

You can try doing:

ldd -d /usr/lib/jriver/Media\ Center\ 25/*.so* | grep -iH found
and
ldd -d /usr/lib/jriver/Media\ Center\ 25/Plugins/*.so* | grep -iH found
and
ldd -d /usr/bin/mediacenter25 | grep -iH found
to see if you are missing anything.

[Hendrik]

So from terminal I first entered gdb mediacenter25 and it returned gdb license info, etc. then returned "Reading symbols from mediacenter25...(no debugging symbols found)...done.

The with gdb still open in the terminal I attempted to start medicenter 25 which crashed as it has been.

From your description, it sounds like one of the steps was misinterpreted. Where it says "run", it literally means type "run" into the gdb terminal, so that gdb starts MC for you. Only then will it be able to catch the error. Do that again, and the next step with "bt full" should have some info.

Oh and for good measure, throw in a "disassemble" command after the "bt full", that should be able to show us what instruction is actually causing the issue.

[designmule]

Thanks Bob and Hendrick

I'll try both suggestions but will start with Hendrick's as it's a correction to my first test.

After typing "run" in the GDB terminal the following is returned:
Starting program: /usr/bin/mediacenter25
[Thread debugging using libthread db enabled]
Using host libthread_db library "/lib/arm-linux-gnueabihf/libthread_db.so.1".
[New Thread 0xb3891410 (LWP 3665)]

Thread 1 "mediacenter25" received signal SIGILL, Illegal instruction.
0xb496fd9c in __gmpz_sizeinbase ()
    from /usr/lib/jriver/Media Center 25/libgmp.so.10

Then after typing "bt full" in the gdb terminal the following is returned:
#0  0xb496fd9c in __gmpz_sizeinbase ()
     from /usr/lib/jriver/Media Center 25/libgmp.so.10
No symbol table info available.
#1 0x01c21218 in ?? ()
No symbol table info available.
Backtrace stopped: previous from identical to this frame (corrupt stack?)

Then after typing "disassemble" in the gdb terminal the following is returned: (I'm typing all of this so beware of typos)
Dump of assembler code for function __gmpz sizeinbase:
  0xb496fd18 <+0>: ldr r3, [r0, #4]
  0xb496fd1c <+4>: ldr r12, [pc, #136] ; 0xb496fdac <__gmpz sizeinnbase+ 148>
  0xb496fd20 <+8>: cmp r3, #0
  0xb496fd24 <+12>: add r12, pc, r12
  0xb496fd28 <+16>: beq 0xb496fda4 <__gmpz_sizeinbase+140>
  0xb496fd2c <+20>: addlt r2, r3, #1
  0xb496fd30 <+24>: subge r2, r3, #-1073741823 ; 0xc0000001
  0xb496fd34 <+28>: push {lr} ; (str lr, [sp, #4]!)
  0xb496fd38 <+32>: lsllt r2, r2, #2
  0xb496fd3c <+36>: lslge r2, r2, #2
  0xb496fd40 <+40>: rsblt r2, r2, #0
  0xb496fd44 <+44>: ldr lr,[r0, #8]
  0xb496fd48 <+48>: cmp r3, #0
  0xb496fd4c <+52>: sub r0, r1, #1
  0xb496fd50 <+56>: rsblt r3, r3, #0
  0xb496fd54 <+60>: tst r0, r1
  0xb496fd58 <+64>: ldr r0, r1
  0xb496fd5c <+68>: clz r0, r0
  0xb496fd60 <+72>: rsb r3, r0, r3, lsl #5
  0xb496fd64 <+76>: ldr r0, [pc, #68] ; 0xb496fdb0 <__gmpz_sizeinbase+ 152>
  0xb496fd68 <+80>: lsl rs, r1, #4
  0xb496fd6c <+84>: add r1, r2, r1, lsl #2
  0xb496fd70 <+88>: ldr r2, [r12, r0]
  0xb496fd74 <+92>: add r1, r2, r1
  0xb496fd78 <+96>: beq 0xb496fd90 <__gmpz_sizeinbase+120>
  0xb496fd7c <+100>: ldr r2, [r1, #4]
  0xb496fd80 <+104>: add r2, r2, #1
  0xb496fd84 <+108>: umull r1, r0, r2, r3
  0xb496fd88 <+112>: add r0, r0,#1
  0xb496fd8c <+116>: pop {pc} ; (ldr pc, [sp], #4
  0xb496fd90 <+120>: ldr r2, [r1, #12]
  0xb496fd94 <+124>: sub r0, r2, #1
  0xb496fd98 <+128>: add r3, r0, r3
  0xb496fd9c <+132>: udiv r0, r3, r2
  0xb496fda0 <+136>: pop {pc} ; (ldr pc, [sp], #4)
  0xb496fda4 <+140>: mov r0, #1
  0xb496fda8 <+144>: bx lr
  0xb496fdac <+148>: andeq r0, r5, r12, ror #24
  0xb496fdb0 <+152>: andeq r0, r0, r4, lsr #11
End of assembler dump.

Whew! Used some keys on the keyboard that don't get much use otherwise. I appreciate the help.
Matt

[designmule]

You can try doing:

ldd -d /usr/lib/jriver/Media\ Center\ 25/*.so* | grep -iH found
and
ldd -d /usr/lib/jriver/Media\ Center\ 25/Plugins/*.so* | grep -iH found
and
ldd -d /usr/bin/mediacenter25 | grep -iH found
to see if you are missing anything.

Running these three commands returned nothing. I'll note that I ran them via ssh for easy copy/paste while for the gdb commands I ran in lxterminal while connected to the sparky via RDP. I've found that if I attempt to start JRiver via ssh I get errors related to starting the display but other commands work fine.

[Hendrik]

Thanks, so its in libgmp. That should help to figure out if something went wrong.
The offending line is 0xb496fd9c, which is "UDIV" - which for some reasons is not available on Cortex-A9 (reference: https://community.arm.com/developer/ip-products/processors/b/processors-ip-blog/posts/divide-and-conquer)

We'll have to figure out how this happened as we try to build stuff with a much more compatible target, usually.

[Hendrik]

I've rebuild our libgmp with proper settings for a compatible binary. Try again with the next release, hopefully it'll be good then (and not any surprises in other binaries either!)

[designmule]

Thanks Hendrik

I updated JRiver to 25.0.87 and no dice. gdb indicates it's still an issue with libgmp.so.10

Maybe your recompile isn't available yet?

[bob]

Thanks Hendrik

I updated JRiver to 25.0.87 and no dice. gdb indicates it's still an issue with libgmp.so.10

Maybe your recompile isn't available yet?

Correct. 25.0.88 or above will have the change

[designmule]

Great! I'll be on the lookout for 88 and will report back with results.

I also want to say that I think it's pretty "next level service" that JRiver software is being modified to troubleshoot a bug experienced by a single user running an obscure ARM device. Thank you both very much.

Matt

[designmule]

.92 seems to start on my sparky. I haven't tested thoroughly but it starts. I appreciate the help.

[Facel]

@designmule => Thank you so much for your post

                          I also have a Sparky board, and already post regarding this problem but my exchanges with
                          JRiver Team did not lead to any solution.
                         
Now I can switch back to MC25 instead of using the Sparky GM Renderer e DLNA client.
(Previously, I had MC24 running without such a problem)

   By the way when you run JRiver in the Desktop environnement (via VNC or via a direct screen and keyboard connected to the sparky) do you also have some "blank windows" for the content panel in the JRiver standard view ?

"blank windows" = there is nothing prompted only a grey color

There is no problem for prompting : Playing Now - Audio - Images - Video

The "blank windows" is when you select :  Streaming - Cloudplay - Drives & Devices - Services & Plug-ins

                         

[Hendrik]

MC on ARM doesn't have a proper web browser yet, which is why those views that use a web browser to display information won't work yet.

[designmule]

@designmule => Thank you so much for your post

                          I also have a Sparky board, and already post regarding this problem but my exchanges with
                          JRiver Team did not lead to any solution.
                         
Now I can switch back to MC25 instead of using the Sparky GM Renderer e DLNA client.
(Previously, I had MC24 running without such a problem)

   By the way when you run JRiver in the Desktop environnement (via VNC or via a direct screen and keyboard connected to the sparky) do you also have some "blank windows" for the content panel in the JRiver standard view ?

"blank windows" = there is nothing prompted only a grey color

There is no problem for prompting : Playing Now - Audio - Images - Video

The "blank windows" is when you select :  Streaming - Cloudplay - Drives & Devices - Services & Plug-ins                       

Facel, MC25 is now working on the Sparky but I have one outstanding issue with JRemote for Andriod not being able to control the Sparky. iOS works fine. A new version of JRemote for Android is on the way, hopefully it fixes the issue. It doesn't sound like you use JRemote for your Sparky so you should be fine to upgrade.

It sounds like Hendrik addressed your issue with blank screens. I have no experience with that.

[Facel]

@designmule=> We are using the same config : an Intel / Nuc based on Windows running JRiver Library server and storing the audio files (Flac)
a Sparky running JRiver as a media renderer /player, and JRemote (Iphone version) as interface for playing music.

initially I had MC24 running on the Sparky but i was obliged to switch back to GM renderer  as I could not get MC25 working on the Sparky.

The most difficult is to succeed to identify which protocol is playing on the Sparky  through JRemote, (between JRiver DLNA, GM Renderer DLNA and JRiver Client.)
The naming is very confusing and each protocol has to be correctly configured, otherwise you can hit the play button on JRemote and nothing happens .
Maybe your Android problem is related to that point? 

Thanks to Hendrik for his answer, you should have the same issue if you are using a screen on your Sparky in order to use JRiver interface (or via remote desktop), anyway this issue is not really critical.

My sparky is headless but I plan to connect a 11" touch screen  in order to prompt the art cover of the album playing (I doubt that the sparky has enough power for running the theater view flawlessly, maybe ?)