Fedora/CentOS (RPM)

[wangmaster 0]

But is it a emby issue or something in fedora 24 that makes it call for /sbin/sh in the systemd script?

 

Greetings yps

I think that this is an emby issue.  Fedora (and by inheritance RHEL and Centos) has a specific locked down SELinux configuration and emby needs to conform to it.  If emby does not, then users will either always have to disable selinux, or figure out alternatives.

 

That's not to say  I'm pointing fingers at emby.  SELinux is a pain in the ass

 

I'm not sure if the /bin/sh thing is simply something that works right now, or if it's actually considered a legitimate workaround for not having a specific selinux policy (or being able to use one of the existing ones).

 

This, as well as the embymagick dependency on boost (which impacts upgradeability to a new fedora version), actually have me in process of converting to the emby docker container.  The tooling around the official docker container for updates seems to have solved some of the issues I have with using docker for a long-running service such as emby, so I'm just putzing around with it now trying to get all the right execution user and selinux sandboxing set up right.

[Luke 39859]

For those using the dev and beta channels, we had some build issues over the last few days that prevented new updates from being published.

 

Thanks to help from @@fc7 we've tracked it down, and dev and beta updates have resumed as normal. The latest builds of Emby Server should be available shortly. 

 

The latest versions also include fixes for Mono 4.4. Please try it out and report your experience. Thanks.

[fc7 123]

Announcement: new packages revisions are available for CentOS/Fedora. The new revisions include the following changes.

 

1. Emby doesn't depend directly on sqlite package anymore. From now on we will be providing a new package called "embysqlite" that will not conflict with the stock sqlite package included in your distro and it will provide Emby with the needed sqlite libraries. In other words now Emby can take full advantage of a newer SQLite library version (3.13.0 at the moment) and at the same time the rest of the system will keep using the stock sqlite package that comes with the distro.
2. Small bugfix on DLL map config file creation (new line char).

The sqlite package from Emby repo is not available anymore and no new or updated versions will be published.

Users that are already using the sqlite package from Emby repo have two options moving forward. Keep the current sqlite package that was installed with Emby (will not receive any further updates) or rollback sqlite to the standard package included in your distro to keep getting update and fixes from the distro provider. For example in CentOS 7 you can rollback to the stock sqlite package executing the following commands:

# wget http://mirror.centos.org/centos/7.2.1511/os/x86_64/Packages/sqlite-3.7.17-8.el7.x86_64.rpm
# rpm2cpio sqlite-3.7.17-8.el7.x86_64.rpm | cpio -idmv
# rpm -e --nodeps sqlite sqlite-libs
# cp -Rp usr/ /
# yum install sqlite
# yum check

This example is provided AS IS and it may need modifications to work with your distribution.

If you are not having any problems with sqlite it's also safe to leave it as is.

 

Enjoy Emby!

[Adamizme 3]

I'm getting this after updating my CentOS 7 emby server:

  Error Code
        DllNotFoundException
    Message
        /usr/lib/libMonoPosixHelper.so
    Stack Trace
        [GetDashboardResource: 8/1/2016 11:37:25 PM]: [REQUEST: {ResourceName:index.html}] System.DllNotFoundException: /usr/lib/libMonoPosixHelper.so at (wrapper managed-to-native) System.IO.Compression.DeflateStreamNative:CreateZStream (System.IO.Compression.CompressionMode,bool,System.IO.Compression.DeflateStreamNative/UnmanagedReadOrWrite,intptr) at System.IO.Compression.DeflateStreamNative.Create (System.IO.Stream compressedStream, CompressionMode mode, Boolean gzip) <0x416b66d0 + 0x00177> in <filename unknown>:0 at System.IO.Compression.DeflateStream..ctor (System.IO.Stream compressedStream, CompressionMode mode, Boolean leaveOpen, Boolean gzip) <0x416b6520 + 0x0008b> in <filename unknown>:0 at System.IO.Compression.DeflateStream..ctor (System.IO.Stream compressedStream, CompressionMode mode) <0x416b64f0 + 0x0001b> in <filename unknown>:0 at (wrapper remoting-invoke-with-check) System.IO.Compression.DeflateStream:.ctor (System.IO.Stream,System.IO.Compression.CompressionMode) at ServiceStack.Support.NetDeflateProvider.Deflate (System.Byte[] bytes) <0x416b6340 + 0x00077> in <filename unknown>:0 at ServiceStack.Support.NetDeflateProvider.Deflate (System.String text) <0x416b62f0 + 0x00037> in <filename unknown>:0 at ServiceStack.StreamExt.Deflate (System.String text) <0x416b62b0 + 0x0002e> in <filename unknown>:0 at ServiceStack.StreamExt.Compress (System.String text, System.String compressionType) <0x416b6190 + 0x0003b> in <filename unknown>:0 at MediaBrowser.Server.Implementations.HttpServer.HttpResultFactory+<GetStaticResult>c__async1.MoveNext () <0x4169d910 + 0x00cbf> in <filename unknown>:0 --- End of stack trace from previous location where exception was thrown --- at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw () <0x7fe1891dfe60 + 0x00029> in <filename unknown>:0 at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess (System.Threading.Tasks.Task task) <0x7fe1891ddd20 + 0x000b3> in <filename unknown>:0 at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification (System.Threading.Tasks.Task task) <0x7fe1891ddc80 + 0x00093> in <filename unknown>:0 at System.Runtime.CompilerServices.TaskAwaiter.ValidateEnd (System.Threading.Tasks.Task task) <0x7fe1891ddc30 + 0x0003a> in <filename unknown>:0 at System.Runtime.CompilerServices.ConfiguredTaskAwaitable`1+ConfiguredTaskAwaiter[TResult].GetResult () <0x7fe1891de4a0 + 0x00017> in <filename unknown>:0 at MediaBrowser.Server.Implementations.HttpServer.HttpResultFactory+<GetStaticResult>c__async0.MoveNext () <0x4169c330 + 0x005e9> in <filename unknown>:0 --- End of stack trace from previous location where exception was thrown --- at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw () <0x7fe1891dfe60 + 0x00029> in <filename unknown>:0 at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess (System.Threading.Tasks.Task task) <0x7fe1891ddd20 + 0x000b3> in <filename unknown>:0 at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification (System.Threading.Tasks.Task task) <0x7fe1891ddc80 + 0x00093> in <filename unknown>:0 at System.Runtime.CompilerServices.TaskAwaiter.ValidateEnd (System.Threading.Tasks.Task task) <0x7fe1891ddc30 + 0x0003a> in <filename unknown>:0 at System.Runtime.CompilerServices.ConfiguredTaskAwaitable`1+ConfiguredTaskAwaiter[TResult].GetResult () <0x7fe1891de4a0 + 0x00017> in <filename unknown>:0 at MediaBrowser.WebDashboard.Api.DashboardService+<Get>c__async0.MoveNext () <0x41697cb0 + 0x00cac> in <filename unknown>:0 

[fc7 123]

We will need a lot more information to try to help you.

 

Are you running Emby stable branch? What are you doing when you get this error (playing music, video, etc)? What is exactly failing? Can you provide a full server log? Can you provide the output of the following commands?

 

rpm -qa | grep emby

rpm -qa | grep mono

rpm -qa | grep sqlite

 

Thanks.

 

 

Sent from my iPhone using Tapatalk

[fc7 123]

Also please provide the output of the following commands:

 

ls -l /usr/lib/libMono*

 

ls -l /usr/lib64/libMono*

 

Thanks

 

 

Sent from my iPhone using Tapatalk

[Adamizme 3]

Thanks for the response! Immediately after updating, that is what I get when trying to browse to the emby web interface either through my apache proxy or directly on port 8096.

 

 

Still using the stable repo, as I have been for a long while now:

http://download.opensuse.org/repositories/home:emby/CentOS_7/home:emby.repo

rpm -qa | grep emby

embysqlite-3.13.0-3.1.x86_64
emby-server-3.0.6020-53.2.x86_64
embymagick-6.9.2-51.3.x86_64

rpm -qa | grep mono

mono-web-4.4.1.0-0.xamarin.1.x86_64
libmonosgen-2_0-1-4.4.1.0-0.xamarin.1.x86_64
mono-reactive-4.4.1.0-0.xamarin.1.x86_64
mono-core-4.4.1.0-0.xamarin.1.x86_64
mono-data-oracle-4.4.1.0-0.xamarin.1.x86_64
dejavu-sans-mono-fonts-2.33-6.el7.noarch
mono-data-4.4.1.0-0.xamarin.1.x86_64
libmonoboehm-2_0-devel-4.4.1.0-0.xamarin.1.x86_64
mono-mvc-4.4.1.0-0.xamarin.1.x86_64
mono-extras-4.4.1.0-0.xamarin.1.x86_64
libmono-2_0-1-4.4.1.0-0.xamarin.1.x86_64
mono-nunit-4.4.1.0-0.xamarin.1.x86_64
liberation-mono-fonts-1.07.2-15.el7.noarch
mono-winforms-4.4.1.0-0.xamarin.1.x86_64
libmono-2_0-devel-4.4.1.0-0.xamarin.1.x86_64
mono-data-sqlite-4.4.1.0-0.xamarin.1.x86_64
mono-winfxcore-4.4.1.0-0.xamarin.1.x86_64
libmonoboehm-2_0-1-4.4.1.0-0.xamarin.1.x86_64
mono-devel-4.4.1.0-0.xamarin.1.x86_64
mono-locale-extras-4.4.1.0-0.xamarin.1.x86_64
libmonosgen-2_0-devel-4.4.1.0-0.xamarin.1.x86_64
mono-wcf-4.4.1.0-0.xamarin.1.x86_64
monodoc-core-4.4.1.0-0.xamarin.1.x86_64
mono-complete-4.4.1.0-0.xamarin.1.x86_64
gnu-free-mono-fonts-20120503-8.el7.noarch

rpm -qa | grep sqlite

sqlite-3.8.2-9.1.x86_64
embysqlite-3.13.0-3.1.x86_64
mono-data-sqlite-4.4.1.0-0.xamarin.1.x86_64

/usr/lib/libMono doesn't exist.

 

ls -l /usr/lib64/libMono*

-rwxr-xr-x 1 root root 968041 Jul 18 14:26 /usr/lib64/libMonoPosixHelper.so

Edited August 2, 2016 by Adamizme

[fc7 123]

I'm not sure is the cause of the problem but I noticed you are running mono 4.4.1 and it's not coming from our repo. Can you please try to uninstall it and use mono 4.2.3.4 from our repo instead?

Uninstalling and reinstalling emby will not affect your data.

 

 

Sent from my iPhone using Tapatalk

[Adamizme 3]

Looks like that resolved it. Thank you for pointing that out!

 

Just for the sake of adding a bit more info - I uninstalled emby server, mono, and libmono then installed mono and emby from emby server repo.

Edited August 2, 2016 by Adamizme

[fc7 123]

Cool.

 

 

Sent from my iPhone using Tapatalk

[fc7 123]

IMPORTANT: for users running mono 4.4 it seems that there is a bug affecting CentOS and Fedora mono packages (maybe other distros using /usr/lib64 as the system library path are affected too). mono 4.2 is NOT affected.

 

You will see a similar exception in Emby server logs (at least during start of the service):

2016-08-08 00:45:47.1884 Error App: Error getting unix name
	*** Error Report ***
	Version: 3.0.6030.0
	Command line: /usr/lib/emby-server/bin/MediaBrowser.Server.Mono.exe -programdata /var/lib/emby-server -restartpath /usr/lib/emby-server/restart.sh
	Operating system: Unix 3.10.0.327
	Processor count: 4
	64-Bit OS: True
	64-Bit Process: True
	Program data path: /var/lib/emby-server
	Mono: 4.4.2 (Stable 4.4.2.11/f72fe45 Sun Aug  7 13:28:51 UTC 2016)
	Application Path: /usr/lib/emby-server/bin/MediaBrowser.Server.Mono.exe
	The type initializer for 'Mono.Unix.Native.Syscall' threw an exception.
	System.TypeInitializationException
	  at MediaBrowser.Server.Mono.Native.BaseMonoApp.GetUnixName () <0x40c58200 + 0x00077> in <filename unknown>:0 
	InnerException: System.DllNotFoundException
	/usr/lib/libMonoPosixHelper.so
	  at (wrapper managed-to-native) Mono.Unix.Native.Syscall:_L_ctermid ()
	  at Mono.Unix.Native.Syscall..cctor () <0x40c585c0 + 0x00093> in <filename unknown>:0 

More information here: https://bugzilla.xamarin.com/show_bug.cgi?id=41953

 

There are several workaround to solve this error. Choose the one that fits best for you:

1. The easiest one is to stay on mono 4.2 until the problem on mono 4.4 is solved. Don't upgrade mono.
2. Create a symlink for the "missing" library and restart Emby service:

   $ sudo ln -s /usr/lib64/libMonoPosixHelper.so /usr/lib/libMonoPosixHelper.so
   

3. Edit /etc/mono/config and remove "$mono_libdir/" from the "MonoPosixHelper" DLL line. Replace this:

   <dllmap dll="MonoPosixHelper" target="$mono_libdir/libMonoPosixHelper.so" os="!windows" />
   

   with this:

   <dllmap dll="MonoPosixHelper" target="libMonoPosixHelper.so" os="!windows" />
   

 

Hopefully this bug will get resolved soon in the upstream projects and no workarounds will be needed.

I will update this thread with any news about this problem.

Edited August 7, 2016 by fc7

[xenu 10]

I just saw this post and couldn't find this error in my startup log. I notice I have a slightly newer Mono version:

CentOS 7.2.1511
Mono JIT compiler version 4.4.2 (Stable 4.4.2.11/f72fe45 Mon Aug 8 22:33:00 UTC 2016)

The file appears to be in the correct path:

$ ll /usr/lib64/libMon*
-rwxr-xr-x. 1 root root 940K Aug  9 00:42 /usr/lib64/libMonoPosixHelper.so

[fc7 123]

If you are using mono packages from Emby repo you are good. They include a patch for the upstream version problem.

 

 

Sent from my iPhone using Tapatalk

[dcrdev 253]

I've had to rebuild my server, which has mean't re-configuring Emby from scratch - I've noticed a couple of issues with the Fedora package, one of which might be intentional the other I would consider to be a bug; I've verified these issues with a virtual machine as well to make sure it's not just my server box.

 

• Firstly the package is no longer downloading prebuilt ffmpeg binaries - there appears to be an empty folder where the ffmpeg binary should be that has a name suggesting an ffmpeg build from February this year. Emby does show you a screen explaining how to manually download the binaries, which is no hassle; but also worth mentioning that Emby for some reason doesn't work with the RpmFusion build of ffmpeg 3.12, the prebuilt binaries work fine though.
• Secondly the startup script seems to be incorrectly setting the mono environment variables on the Fedora platform, for example libgdiplus which mono is looking to source from /usr/local/lib/ where as the Fedora libgdiplus package installs to /usr/lib/. It seems impossible to override the environment variables without modifying the startup script as for some reason that is taking precedence over /etc/emby-server.conf. For now a quick and dirty fix is to do a symlink i.e. "ln -s /usr/lib/libgdiplus.so /lib/libgdiplus.so" - but I'm concerned that other libraries may be impacted as well.

As I say I've tested this on a fresh Fedora 24 Server virtual machine to verify these findings against my main box.

Edited September 3, 2016 by dcrdev

[Luke 39859]

We actually only use libgdiplus as a fallback, so i think the statement about environment variables is more like we're not doing anything at all and that's just what happens to be there.

 

for image processing we use image magick, and if that is not available then we fallback to legacy gdi-based processing which doesn't quite have as many features. i saw your comment in the other thread earlier but i don't know where that error message about gdi is coming from.

[Luke 39859]

Ok, I see what's happening. The tv headend plugin is using gdi libraries. I need to let Tolotos know that he can't assume they will be available:

https://github.com/MediaBrowser/Emby.Plugins/blob/edb60012771ffde29583fcf4f22ae0171ae55eb5/TVHeadEnd/HTSConnectionHandler.cs#L186

[dcrdev 253]

Thanks Luke wasn't aware that gdi was a fallback - however I can say that this issue of the wrong/no path being passed to mono is a new occurrence, it didn't happen a couple of (rpm) builds ago; if it's no longer being used though I suppose it's a non issue.

[alB24 0]

No installation package for Fedora24 emby-server available.

 

 

[root@@Localhost ~]# dnf config-manager --add-repo http://download.opensuse.org/repositories/home:emby/fedora24/home:emby.repo
Adding repo from: http://download.opensuse.org/repositories/home:emby/fedora24/home:emby.repo
Status code: 404 for http://download.opensuse.org/repositories/home:/emby/fedora24/home:emby.repo
[root@@Localhost ~]# dnf install emby-server
Last metadata expiration check: 1:58:13 ago on Thu Sep 22 07:36:10 2016.
No package emby-server available.
Error: Unable to find a match.
 

[fc7 123]

Your intent to add the repo is failing (404 error). Hence why the package is missing (no repo in the first place).

I will look into it later.

 

 

Sent from my iPhone using Tapatalk

[dcrdev 253]

The fedora packages haven't been updated in a while - are there any plans to push out the latest version?

[fc7 123]

The fedora packages haven't been updated in a while - are there any plans to push out the latest version?

 

What do you mean? Just checked OBS repos and both F23 and F24 are up to date with Emby stable version.

 

Which version of Fedora are you running? We only provide packages for Fedora versions that are not EOL (meaning current and previous version only -as Fedora does-).

 

You can check the repo manually: http://download.opensuse.org/repositories/home:/emby/Fedora_24/x86_64/

 

First package on the list:

emby-server-3.0.7300-79.1.x86_64.rpm 

Edited October 6, 2016 by fc7

[dcrdev 253]

Something strange seems to have happened -

 

On the server dashboard it states I'm on version 3.0.7200.0, dnf lists no available package updates and clearing the cache i.e. "dnf clean all" does not help. However running a query against rpm yields the following package name "emby-server-3.1.6106.19259-dev-76.1.x86_64" which is presumably the nightly version and not stable?

 

This is not something I have done - so not sure what's happened?

 

Also yes I'm on Fedora 24.

Edited October 7, 2016 by dcrdev

[fc7 123]

Something strange seems to have happened -

 

On the server dashboard it states I'm on version 3.0.7200.0, dnf lists no available package updates and clearing the cache i.e. "dnf clean all" does not help. However running a query against rpm yields the following package name "emby-server-3.1.6106.19259-dev-76.1.x86_64" which is presumably the nightly version and not stable?

 

This is not something I have done - so not sure what's happened?

 

Also yes I'm on Fedora 24.

There was a problem with all Emby repos a few weeka ago that caused dev version to go into stable channel. Maybe that's the problem (if you happen to update Emby while the problem was going on).

 

The fix should be easy. Just remove and reinstall emby-server package and you should be good. You data should be remain untouched.

 

 

 

Sent from my iPhone using Tapatalk

[dcrdev 253]

There was a problem with all Emby repos a few weeka ago that caused dev version to go into stable channel. Maybe that's the problem (if you happen to update Emby while the problem was going on).

 

The fix should be easy. Just remove and reinstall emby-server package and you should be good. You data should be remain untouched.

 

 

 

Sent from my iPhone using Tapatalk

 

Yep that worked, thank you!

[altramarine 21]

CentOS7 here and I had the same issue with the repo.

II removed and reinstalled emby package and received the latest build.

However, today I see a newer version 3.0.8200 available for download but "yum update" doesn't give me that option.

Do I have to reinstall again?

Thanks,