Jump to content

Getting the CoverArt Plugin Working


solabc16

Recommended Posts

solabc16

Evening

 

This is still a work in progress, but decided to write up where I've got to so far with this - partly for my own benefit, and I'm sure some of you will have some ideas as well.

 

The configuration is a DS1815+ running DSM 5.2-5644 Update 5, with Emby Server v3.0.5882.0.

 

The server setup is pretty conventional and as described here, http://emby.media/community/index.php?/topic/22921-synology-setup/. Out of the box, with this configuration, you will notice the following in the server log files:-

2016-03-05 10:54:20.5555 Error App: Error loading ImageMagick. Will revert to GDI.
2016-03-05 10:54:20.5732 Error App: Error loading GDI. Will revert to NullImageEncoder.
2016-03-05 10:54:36.5248 Error CoverArt: ImageMagick unavailable. CoverArt requires ImageMagick

A quick fix to this is to edit ImageMagickSharp.dll.config and change the linux target to libMagickWand-6.Q16.so, as the package installed when using the build available in package centre is a Q16 build.

<configuration>
  <dllmap dll="CORE_RL_Wand_.dll" target="libMagickWand-6.Q16.so" os="linux"/>
  <dllmap dll="CORE_RL_Wand_.dll" target="libMagickWand-6.so" os="freebsd,openbsd,netbsd"/>
  <dllmap dll="CORE_RL_Wand_.dll" target="./MediaInfo/osx/libmediainfo.dylib" os="osx"/>
</configuration>

You can get the ImageMagick version information by running ./identify --version from the ImageMagick installation.

2016-03-05 16:48:21.2133 Info ImageMagick: ImageMagick version: ImageMagick 6.9.1-4 Q16 x86_64 2015-06-05
http://www.imagemagick.org

Restarting Emby server confirms this works, but it's not the whole story: image loading is initially sluggish within the webapp (although helped greatly from caching) and does not work at all within Emby Theatre (and iOS), I'm still working to get to the bottom of understanding the issue here. With this change, you now get the following in the server log files:-

2016-03-05 12:22:44.0697 Info ImageMagick: ImageMagick version: ImageMagick 6.9.1-4 Q16 x86_64 2015-06-05 http://www.imagemagick.org
2016-03-05 12:23:00.3705 Info CoverArt: ImageMagick version: ImageMagick 6.9.1-4 Q16 x86_64 2015-06-05 http://www.imagemagick.org

Which, gives you the expected eye candy in the UI:-

 

56dc98e0b31fc_latest.png

 

My initial suspicions around the poor performance, is that it's related to the build available via the community being a Q16 build. To that end, I've rebuilt ImageMagick (on the above platform), so that we have a Q8 build to test with. I've stuck with v6.9.1-4 as some of the newer versions threw up some build issues that I didn't want to get distracted by; at least not yet. Here's the output from identify for this build:-

./identify --version
Version: ImageMagick 6.9.1-4 Q8 x86_64 2016-03-06 http://www.imagemagick.org
Copyright: Copyright (C) 1999-2015 ImageMagick Studio LLC
License: http://www.imagemagick.org/script/license.php
Features:  Cipher
Delegates (built-in): bzlib fontconfig freetype jng jpeg lcms png tiff zlib

However, with the ImageMagickSharp.dll.config changed back to target libMagickWand-6.Q8.so, CoverArt again fails to load due to ImageMagick failing. For testing, I made a backup of the Q16 build and placed the Q8 build directly in it's place. From the command line, the installation appears good - identify works and I can perform some simple image manipulations.

2016-03-05 10:54:20.5555 Error App: Error loading ImageMagick. Will revert to GDI.
2016-03-05 10:54:20.5732 Error App: Error loading GDI. Will revert to NullImageEncoder.
2016-03-05 10:54:36.5248 Error CoverArt: ImageMagick unavailable. CoverArt requires ImageMagick

Is it possible (Luke?), to get the detailed error information behind "Error App: Error loading ImageMagick. Will revert to GDI.", so I can get a better handle on where to start looking?

 

Best

- James

 

 

 

Link to comment
Share on other sites

Well done. There isn't really any detailed information to offer. The config file is looking for a specific version. if yours doesn't match, you need to adjust the config file. When we eventually have a synology package for easy installation, i imagine it will all be handled by the pacakge.

Link to comment
Share on other sites

solabc16

Evening

 

This is the configuration file as it currently stands...

<configuration>
  <dllmap dll="CORE_RL_Wand_.dll" target="libMagickWand-6.Q8.so" os="linux"/>
  <dllmap dll="CORE_RL_Wand_.dll" target="libMagickWand-6.so" os="freebsd,openbsd,netbsd"/>
  <dllmap dll="CORE_RL_Wand_.dll" target="./MediaInfo/osx/libmediainfo.dylib" os="osx"/>
</configuration>

Here's the libMagickWand related contents of /volume1/@appstore/imagemagick/lib, which currently contains my Q8 build from this afternoon...

lrwxrwxrwx    1 root     root            27 Mar  6 21:43 libMagickWand-6.Q8.so -> libMagickWand-6.Q8.so.2.0.0
lrwxrwxrwx    1 root     root            27 Mar  6 21:43 libMagickWand-6.Q8.so.2 -> libMagickWand-6.Q8.so.2.0.0
-rwxr-xr-x    1 root     root       1872100 Mar  6 21:43 libMagickWand-6.Q8.so.2.0.0

These are the libMagickWand related files provided by the community package...

lrwxrwxrwx    1 root     root            28 Mar  6 21:40 libMagickWand-6.Q16.so -> libMagickWand-6.Q16.so.2.0.0
lrwxrwxrwx    1 root     root            28 Mar  6 21:40 libMagickWand-6.Q16.so.2 -> libMagickWand-6.Q16.so.2.0.0
-rwxr-xr-x    1 root     root       1713664 Mar  6 21:40 libMagickWand-6.Q16.so.2.0.0

So at the moment, I'm not changing much other than the Q16 to Q8 in /volume1/@appstore/emby/share/emby/ImageMagickSharp.dll.config after swapping the contents of /volume1/@appstore/imagemagick.
 

The file exists and is in the same location as when Emby Server successfully loads the Q16 version, so I don't believe it's because it can't find the file per se; perhaps it's an  issue with the build flags/entry points.

 

Can you point me at the code that's making the call, perhaps that will give some further insight. Reading through this thread, http://emby.media/community/index.php?/topic/23002-imagemagick/, it looks like the server used to log the exception - which would certainly help.

 

Best

- James
 

 

 

 

 

 

Link to comment
Share on other sites

i don't think the code will help you. all it does is try to load the image magick library and determine the version number. You're right, it's probably not a file not found issue, but more likely something with the ImageMagick build. There could be something it depends on that is missing.

Link to comment
Share on other sites

solabc16

Evening

 

Could we add something like this to 'private IImageEncoder GetImageEncoder()' in Emby/MediaBrowser.Server.Startup.Common/ApplicationHost.cs?

private IImageEncoder GetImageEncoder()
{
    if (!_startupOptions.ContainsOption("-enablegdi"))
    {
        try
        {
            return new ImageMagickEncoder(LogManager.GetLogger("ImageMagick"), ApplicationPaths, HttpClient, FileSystemManager, ServerConfigurationManager);
        }
        catch (Exception ex)
        {
            Logger.Error("Error loading ImageMagick. Will revert to GDI.");
            
            // Write more detailed information to the log if debug is enabled.
            Logger.ErrorException("GDI not enabled, failed to create [ImageMagickEncoder].", ex);
        }
    }

    try
    {
        return new GDIImageEncoder(FileSystemManager, LogManager.GetLogger("GDI"));
    }
    catch (Exception ex)
    {
        Logger.Error("Error loading GDI. Will revert to NullImageEncoder.");

        // Write more detailed information to the log if debug is enabled. (added for consistency)
        Logger.ErrorException("GDI enabled, failed to create [GDIImageEncoder].", ex);

    }

    return new NullImageEncoder();
}

Looking back through the history, it looks like this is what used to happen. I understand the need for a cleaner log when the debug flag is not set, but this would help in the cases where we're trying to troubleshoot something.

 

- James

Edited by solabc16
Link to comment
Share on other sites

solabc16

Look like the formatting got lost, these are the additions...

   // Write more detailed information to the log if debug is enabled.
   Logger.ErrorException("GDI not enabled, failed to create [ImageMagickEncoder].", ex);

...and...

    // Write more detailed information to the log if debug is enabled. (added for consistency)
    Logger.ErrorException("GDI enabled, failed to create [GDIImageEncoder].", ex);

- James

Edited by solabc16
Link to comment
Share on other sites

solabc16

A quick update on the second of the two problems I'm looking at with CoverArt, with images only being returned in the WebUI.

(this is with the community released Q16 build of ImageMagick)

 

I proxied some requests from ET and it appears that the server simply does not respond at all to the image requests, well at least for the five minutes I left it for. I was hoping to see a timeout or exception of somet description to give me some pointers.

 

All requests exhibit the same behaviour, here's an example:-

http://192.168.236.105:8096/emby/Items/494c144aabb1688c89567e32edc38b43/Images/Primary?maxHeight=365&maxWidth=243&tag=ee0d72441b269beb7deaceee96209135&quality=90&accept=webp

The request is seen at the server:-

2016-03-07 21:08:44.0430 Info HttpServer: HTTP GET http://192.168.236.105:8096/emby/Items/494c144aabb1688c89567e32edc38b43/Images/Primary?maxHeight=365&maxWidth=243&tag=ee0d72441b269beb7deaceee96209135&quality=90&accept=webp. UserAgent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:44.0) Gecko/20100101 Firefox/44.0

Eventually the server stops responding, I suspect due to a concurrent request limit. It doesn't crash and quitting the applications generating the requests restores the server to normal operation. The successful requests being made from the WebUI look like this:-

http://192.168.236.105:8096/emby/Items/c2975e19519eafc870e8d46f8aea9e1c/Images/Primary?maxHeight=450&maxWidth=300&tag=06b7c0db5d57660d18f9df27021c76ab&enableImageEnhancers=true&quality=90

- James

Link to comment
Share on other sites

solabc16

...decided to look at it for a few more minutes, it appears the issue is being caused by the parameters being passed for maxHeight and maxWidth.

 

With the parameters as passed from ET captured by the proxy, this request hangs:-

http://192.168.236.105:8096/emby/Items/494c144aabb1688c89567e32edc38b43/Images/Primary?maxHeight=365&maxWidth=243&tag=ee0d72441b269beb7deaceee96209135&quality=90&accept=webp

Change maxHeight and maxWidth to 450 and 300 respectively (as used by the WebUI), and the request is successful:-

http://192.168.236.105:8096/emby/Items/494c144aabb1688c89567e32edc38b43/Images/Primary?maxHeight=450&maxWidth=300&tag=ee0d72441b269beb7deaceee96209135&quality=90&accept=webp

- James

Edited by solabc16
Link to comment
Share on other sites

good investigation although the max size params don't really mean anything because they're not the root cause. i suspect you're right about a concurrency limit. there is probably a failure that is hanging instead of throwing an exception, thus causing the lock to never be released.

Link to comment
Share on other sites

solabc16

Evening

 

Indeed, but at least a reasonably straighforward scenario now to reproduce, independent of any of the client apps.

 

I'm in the process of creating a dev environment for Linux/Mono, so I can't take this any further at the moment.

 

If nobody gets to it first, I'll post back here what I find, once I have it up and running.

 

I should be able to test on a Red Hat/CentOS inststallation as well sooner, so that will give some idication as to whether this is a platform specific issue or a more general issue with the Mono builds.

 

- James

Link to comment
Share on other sites

I think if there were a cover art issue we would see it in the windows release.  my guess is either something in unmanaged code is hanging (imagemagick), or there's a bug with the mono implementation of SemaphoreSlim. The latter wouldn't surprise me because there have been other mono bugs related to multi-threading and concurrency that have forced us to find new ways of doing things.

Link to comment
Share on other sites

solabc16

Evening

 

I setup an instance of Emby Server on a vanilla CentOS installation [Linux release 7.2.1511 (Core)], and no problems with CoverArt via the WebUI or EM.

 

iOS apps do not however show the CoverArt versions of the images, is that expected?

 

So this would suggest the problem is either with Mono on Synology or the current version of ImageMagick available for the platform.

 

My next step I think will be to build a version of ImageMagick for Synology (DS1815+) that is equivalent to the one shipped with the CentOS package and see where that takes us.

 

Best

- James

Link to comment
Share on other sites

Yes for iOS app it's by design right now. They have pretty strict memory requirements and the larger output that comes from Cover Art isn't ideal for it right now.

Link to comment
Share on other sites

solabc16

Evening

 

Made some progress on this one, so here's an update. There was a mono update during the last few days for Synology (DS1815+), this didn't change the behaviour.

 

For reference, the change was as follows:-

LATEST   : Mono: 4.2.2 (Stable 4.2.2.30/996df3c Thu Mar 17 11:46:47 CET 2016)
PREVIOUS : Mono: 4.2.1 (Stable 4.2.1.102/6dd2d0d Mon Nov 30 14:47:31 CET 2015)

Having worked through the build issues with the latest version of ImageMagick (6.9.3-7), I've successfully built a Q8 version of ImageMagick for the Synology DS1815+ platform; this was done on Centos (7.2).

 

Emby Server loaded the library successfully...

2016-03-19 18:03:22.4799 Info ImageMagick: ImageMagick version: ImageMagick 6.9.3-7 Q8 x86_64 2016-03-19 http://www.imagemagick.org
2016-03-19 18:03:38.1139 Info CoverArt: ImageMagick version: ImageMagick 6.9.3-7 Q8 x86_64 2016-03-19 http://www.imagemagick.org

...and both issues I'm pleased to say are resolved. Images are now loading properly and imaging loading is quick in both the WebUI and ET.

 

With a little tweaking of the optional features, I was able to mimic the configuration of the version installed by Package Center.

 

Package Centre

Version: ImageMagick 6.9.1-4 Q16 x86_64 2015-06-05 http://www.imagemagick.org
Copyright: Copyright (C) 1999-2015 ImageMagick Studio LLC
License: http://www.imagemagick.org/script/license.php
Features:  Cipher DPC
Delegates (built-in): freetype jng jpeg png tiff zlib

My Build

Version: ImageMagick 6.9.3-7 Q8 x86_64 2016-03-19 http://www.imagemagick.org
Copyright: Copyright (C) 1999-2016 ImageMagick Studio LLC
License: http://www.imagemagick.org/script/license.php
Features: Cipher DPC
Delegates (built-in): freetype jng jpeg png tiff zlib

Here's the improved view in ET:-

 

56eda177a9669_et_coverart.png

 

This build of ImageMagick should be good for any Intel x86_64 based Synology (DSM5) platform, so if you're experiencing the same issues and would like the binaries or help building from source let me know.

 

Best

- James

  • Like 1
Link to comment
Share on other sites

  • 2 weeks later...
Pirlo1966

This build of ImageMagick should be good for any Intel x86_64 based Synology (DSM5) platform, so if you're experiencing the same issues and would like the binaries or help building from source let me know.

 

Best

- James

 

 

Yes please, binaries would be great!

Edited by ehgeahrev
Link to comment
Share on other sites

  • 3 weeks later...
solabc16

Evening

 

A couple more details I should have included in my earlier post for completeness. Here are the dependencies and their versions used for this build:-

 

    libfreetype.so.6.12.0

    libjpeg.so.9.2.0

    libpng16.so.16.21.0

    libtiff.so.5.2.4

    libz.so.1.2.8

 

Luke - done.

 

ehgeahrev - binaries attached (well not at the moment as too large - 13MB and 'not permitted'), as noted above only tested on DS1815+ with DSM 5.2-5644 Update 5. Initial package installed to /volume1/@appstore/imagemagick/ using PackageCenter, as per Luke's installation instructions. These files then backed up and replaced with the attached.

 

Best

- James

Link to comment
Share on other sites

yes just click more reply options and attach the file, then i'll attach it to the first post. thanks!

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...