More > JRiver Media Center 24 for Linux

JRiver Media Center 24.0.31 BETA for Debian Jessie (amd64, i386 and arm)

<< < (6/8) > >>

Awesome Donkey:
Okay, let's go through the list... I'll do my main Arch Linux install after I go through all the VMs (just in case it's different) and edit this post. I don't have a Fedora VM right now, so can't test that one. :P

Arch Linux (main install):


--- Code: ---libjpeg.so.8 => /usr/lib/libjpeg.so.8 (0x00007f9ec9bfc000)
--- End code ---

Arch Linux VM:


--- Code: ---libjpeg.so.8 => /usr/lib/libjpeg.so.8 (0x00007f57869df000)
--- End code ---

Debian Stretch VM:


--- Code: ---libjpeg.so.62 => /usr/lib/x86_64-linux-gnu/libjpeg.so.62 (0x00007f50e8eac000)
--- End code ---

Ubuntu 18.04 VM:


--- Code: ---libjpeg.so.8 => /usr/lib/x86_64-linux-gnu/libjpeg.so.8 (0x00007fad4efb7000)
--- End code ---

Linux Mint 18.3 VM:


--- Code: ---libjpeg.so.8 => /usr/lib/x86_64-linux-gnu/libjpeg.so.8 (0x00007f34d144b000)
--- End code ---

I suspect the main Arch Linux install will be the same as the VM.

EDIT: Added Arch Linux main install result.

Hendrik:
The coverart issue is possibly fixed for the next build, don't need more info so far. We'll be testing those changes on Monday. Maybe we can also figure out why the browser doesn't work on Ubuntu 18.04.

Awesome Donkey:

--- Quote from: Hendrik on June 01, 2018, 06:12:58 pm ---The coverart issue is possibly fixed for the next build
--- End quote ---

Just curious, what was the (possible) issue that caused it?

Hendrik:
Our version of libjpeg-turbo was colliding with the version of libjpeg the web browser dependency was pulling in. But thats not really a big problem since our jpeg handling was supposed to be isolated to libJRImage.so, but some isolation was not being setup the way it should be.

Kott:
OpenSUSE Tumbleweed:

ldd /usr/bin/mediacenter24 | grep jpeg
        libjpeg.so.8 => /usr/lib64/libjpeg.so.8 (0x00007fe18c720000)

Navigation

[0] Message Index

[#] Next page

[*] Previous page