solabc16 379 Posted March 6, 2016 Share Posted March 6, 2016 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:- 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 More sharing options...
Luke 37068 Posted March 6, 2016 Share Posted March 6, 2016 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 More sharing options...
solabc16 379 Posted March 6, 2016 Author Share Posted March 6, 2016 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 More sharing options...
Luke 37068 Posted March 6, 2016 Share Posted March 6, 2016 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 More sharing options...
solabc16 379 Posted March 7, 2016 Author Share Posted March 7, 2016 (edited) 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 March 7, 2016 by solabc16 Link to comment Share on other sites More sharing options...
Luke 37068 Posted March 7, 2016 Share Posted March 7, 2016 what is the change that you made? Link to comment Share on other sites More sharing options...
solabc16 379 Posted March 7, 2016 Author Share Posted March 7, 2016 (edited) 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 March 7, 2016 by solabc16 Link to comment Share on other sites More sharing options...
solabc16 379 Posted March 7, 2016 Author Share Posted March 7, 2016 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 More sharing options...
solabc16 379 Posted March 7, 2016 Author Share Posted March 7, 2016 (edited) ...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 March 7, 2016 by solabc16 Link to comment Share on other sites More sharing options...
Luke 37068 Posted March 7, 2016 Share Posted March 7, 2016 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 More sharing options...
solabc16 379 Posted March 8, 2016 Author Share Posted March 8, 2016 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 More sharing options...
Luke 37068 Posted March 9, 2016 Share Posted March 9, 2016 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 More sharing options...
solabc16 379 Posted March 13, 2016 Author Share Posted March 13, 2016 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 More sharing options...
Luke 37068 Posted March 13, 2016 Share Posted March 13, 2016 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 More sharing options...
solabc16 379 Posted March 13, 2016 Author Share Posted March 13, 2016 Ok, thanks for clarifying, will stop me chasing ghosts. - James Link to comment Share on other sites More sharing options...
solabc16 379 Posted March 19, 2016 Author Share Posted March 19, 2016 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:- 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 1 Link to comment Share on other sites More sharing options...
Luke 37068 Posted March 19, 2016 Share Posted March 19, 2016 Awesome thanks! Can you please mention this here as well: https://github.com/SynoCommunity/spksrc/pull/1673 Thanks. Link to comment Share on other sites More sharing options...
Pirlo1966 22 Posted April 1, 2016 Share Posted April 1, 2016 (edited) 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 April 1, 2016 by ehgeahrev Link to comment Share on other sites More sharing options...
solabc16 379 Posted April 17, 2016 Author Share Posted April 17, 2016 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 More sharing options...
Luke 37068 Posted April 17, 2016 Share Posted April 17, 2016 Good info, thanks! Do any instructions need modifications? Link to comment Share on other sites More sharing options...
solabc16 379 Posted April 17, 2016 Author Share Posted April 17, 2016 Evening No, I wouldn't say so, this can be used for now (on this platform at least) as a drop-in replacement for the version installed via the instructions detailed here http://emby.media/community/index.php?/topic/22921-synology-setup/?p=224173. Anyway/anywhere to upload a 14MB tar.gz here? Best - James Link to comment Share on other sites More sharing options...
Luke 37068 Posted April 17, 2016 Share Posted April 17, 2016 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 More sharing options...
solabc16 379 Posted April 17, 2016 Author Share Posted April 17, 2016 I tried, but file limit appears to be 10MB and also got the message 'file type not allowed'. Link to comment Share on other sites More sharing options...
solabc16 379 Posted April 17, 2016 Author Share Posted April 17, 2016 I should add, working well and looking good in tvOS as well... - James Link to comment Share on other sites More sharing options...
Luke 37068 Posted April 17, 2016 Share Posted April 17, 2016 Very nice. Are you able to upload to something like dropbox or any similar place? Link to comment Share on other sites More sharing options...
Recommended Posts
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 accountSign in
Already have an account? Sign in here.
Sign In Now