libMagickWand-6.Q8.so System.DllNotFoundException

[blindpet 0]

I am trying to install Emby on an ARMv7 device because somebody requested it. I have compiled and installed all the newest dependencies and I am getting this error:

 

libMagickWand-6.Q8.so

System.DllNotFoundException

 

I compiled and installed the latest imagemagick, any suggestions?

[thefirstofthe300 291]

If you run the following from a bash shell:

MAGICKWAND=$(ldconfig -p | grep MagickWand.*.so$ | cut -d" " -f4)
echo ${MAGICKWAND##*/}

That will give you the name of the MagickWand dll. Then replace the target in /path/to/installation/ImageMagickShard.dll.config with the output of the above. Then you should have a working ImageMagick installation.

 

I would bet that you don't have the Q8 version of ImageMagick is your problem.

[blindpet 0]

Thank you that solved it. It is now running and I will do some tests and post the guide eventually.

 

I know many ARMv7 users are looking for alternatives to Plex because Plex has transcoding disabled on ARM devices. Is it worth it for me to compile an ffmpeg with all the supported libs for using on ARM devices or are they just too weak? If emby will at least try to transcode that would be useful too so users can understand the limitations of their devices.

 

Also is there a table with which emby clients require transcoding or not?

[Luke 37184]

no client requires transcoding. they simply choose the best available option for playback. sometimes that's direct stream, other times it's transcoding, etc.

[blindpet 0]

no client requires transcoding. they simply choose the best available option for playback. sometimes that's direct stream, other times it's transcoding, etc.

How does the client choose transcoding? Do you make sure all of the necessary codecs are installed on the client builds?

 

For Plex it is ridiculously fragmented and there is no frame of reference anywhere with a table showing which devices require transcoding for certain codecs. If you have anything more specific than 'sometimes it's direct stream sometimes it's transcoding' it could save a lot of users time and possible frustration. If for example XviD needs to be transcoded on Chromecasts or Android clients and a user has a library full of those then they could choose to not try or convert their library etc. If this sort of information exists somewhere that would be awesome.

[Luke 37184]

the criteria for direct play/direct stream is if the device can play it natively, if it falls within user-configured client bitrate settings, and any server-configured administrative settings.

 

but most of all, whether the client device supports the content or not.

[blindpet 0]

the criteria for direct play/direct stream is if the device can play it natively, if it falls within user-configured client bitrate settings, and any server-configured administrative settings.

 

but most of all, whether the client device supports the content or not.

I am doing tests now and xvid and divx files are not being played back at all on an Android client. It doesn't even attempt to play. The same file plays back fine natively on the device with another player. I am connected locally so there is no remote access outside my network going on. So when you say the client device supports the content or not you mean whether the emby app on the client supports the content, right?

 

I'm guessing there is no list for these codecs and devices (which would be ideal) but I would love to know why some content is not even attempted to be played, is there a way to make it use the xvid codec?

 

The mkv file (haven't checked codec) is playing back fine

[gsnerf 26]

I think there is some confusion around the term 'natively' in this case. When Luke talks about 'natively' I think he means, that the codec for the specific video file has to be available and useable without extra tooling in the target system. As far as I now android doesn't provide such codecs for xvid or divx. The other client you are using propably packages such a codec, so that it can directly play these videofiles. I don't think any emby client actually packs additional codecs.

 

I think there is an exception to the native-rule: the web client is limited to the codecs the respective browser engine supports! So even though you might have a working xvid/divx codec on your PC that won't help playing such codecs in the emby web client.

[blindpet 0]

Thanks for the clarification gsnerf. Does this mean emby cannot have codecs embedded in the client? It seems to be a major limitation for these media server packages (Plex has them too) and was really hoping emby didn't. What about the emby kodi plugin, same story?

 

I have compiled ffmpeg with libxvid so will see if emby will try and transcode to the app.

[Luke 37184]

some can, some can't. but not the web browser

[gsnerf 26]

Does this mean emby cannot have codecs embedded in the client? It seems to be a major limitation for these media server packages (Plex has them too) and was really hoping emby didn't. What about the emby kodi plugin, same story?

 

I don't think there is a rule for emby clients to not package any codecs, the developers simply chose not to (propably for licensing reasons).

 

Actually you need to have codec support on both sides, server and client. The server needs to at least be able to read the source codec to be able to recode in a format the client will understand. This usually isn't a problem, as that simply means that the system with the server needs an ffmpeg version compiled with any needed codec which should be a given for most packages we provide (gentoo beeing the exception, as you can define wanted support before install).

 

Client side is up to the specific developer. For kodi I think the emby plugin simply embeds and can play whatever regular kodi can play anyways. I think it also uses ffmpeg, so codec support in ffmpeg should be all needed there. From experience I would say kodi can play almost anything you throw at it, so using it should almost always result in direct play. If you can play a file locally it should also direct play from emby server.

[Luke 37184]

It is something we would like to do for android, we just haven't gotten to it yet. It's all open source and everyone is welcome to help out.

[blindpet 0]

I wish I could help but I'm not a dev.

 

I have now compiled ffmpeg with libx264 and libxvid, it is still not even attempting transcoding from the Banana Pi server when playing to the Android app over wifi. Actually since I installed the custom ffmpeg mkv won't even play back in the Android app while it did before with a vanilla ffmpeg.

[gsnerf 26]

I am assuming you are talking about the ffmpeg on the server side? You will need to make sure to add support for all codecs (video and audio) when compiling your custom ffmpeg build. As MKV is a container format you'll have to take a look what video and audio codecs are used in your files and make sure you have support for that codecs in your custom build. Audio codecs commonly used are aac/aac+ or mp3 so make sure you add support for that.

[blindpet 0]

Yes on the server side. I followed this guide so pretty much all libs are included. Like I said the mkv played before with a vanilla ffmpeg, makes no sense to me that it now doesn't when ffmpeg has more functionality.

[tekkb 13]

Most people are having problems with their build of ImageMagick because they are not configuring it with quantum 8 and webp before compiling. Look at the options for copnfiguring. Also, running ldd command on the libMagickW-6.Q8.so file will show any dependencies you are missing.

 

Sent from my SM-T530NU using Tapatalk

Edited April 15, 2015 by tekkb

[blindpet 0]

Thank you, I will recompile imagemagick later. Any special version of quantum 8 or webp needed when compiling on arm (they tend to be behind on versions)?

 

I don't see how to compile it with webp on their documentation page can you point me to somewhere that will show me how?

Edited April 15, 2015 by blindpet

[tekkb 13]

I only have an older armv6 device, besides a tablet. So I haven't compiled anything for arm. I compiled for amd64 and only had to compile ImageMagick and webp. Good Luck! And please share your findings on OMV forum.

 

Sent from my SM-T530NU using Tapatalk

Edited April 15, 2015 by tekkb

[blindpet 0]

I only have an older armv6 device, besides a tablet. So I haven't compiled anything for arm. I compiled for amd64 and only had to compile ImageMagick and webp. Good Luck! And please share your findings on OMV forum.

 

Sent from my SM-T530NU using Tapatalk

I thought i recognized your avatar . If I can get everything built properly I hope it will get added to the OMV extras repo, still waiting for Sonarr and the mono I compiled to get added for ARM

[tekkb 13]

hehe, I will work on 32 bit this weekend.

./configure --with-webp=yes --with-quantum-depth=8

 

Make sure you run this once you have the ImageMagick and webp libraries installed:

 

ldconfig /usr/local/lib

 

I'm back to sleep... zzzzz

Sent from my SM-T530NU using Tapatalk

Edited April 15, 2015 by tekkb

[blindpet 0]

And install libwebp-dev I think. What about libmagick? If I use the unstable repo I can get these two libmagickwand-6.q16-dev imagemagick-6.q16 but have not found a q8 version.

[tekkb 13]

You do not need an unstable repo. The q8 version is created when you configure and compile correctly with that quatum line. See my edited prior post. I added to it.

 

Sent from my SM-T530NU using Tapatalk

[Lynxy 0]

./configure --with-webp=yes --with-quantum-depth=8

 

Make sure you run this once you have the ImageMagick and webp libraries installed:

 

ldconfig /usr/local/lib

 

Thank you for this! I was having a terrible time with HUGE images at their original quality (100%?) being downloaded on a slow connection. With as many images as you see on the home screen, show listing, season listing, etc, this was quite the problem.

 

I am running Linux with the official Emby apt repo added. Through there, installing Emby also installed a package called 'embymagick' which provides /usr/lib/emby-server/x86_64-linux-gnu/libEmbyMagickWand-6.Q8.so. Unfortunately, for whatever reason, this library does nothing to resample images. Don't waste your time persuing this route!

 

Thanks to tekkb I no longer have this issue, so thank you! For those who are experiencing this same issue, here is what I did to fix it explained a little further:

• Download ImageMagick 6 from the official Github mirror: https://github.com/ImageMagick/ImageMagick/tree/ImageMagick-6
  • Make sure you are pulling from the ImageMagick-6 branch, not master!
• Unzip, cd, and run:
  • ./configure --with-webp=yes --with-quantum-depth=8
  • make
  • make install
  • ldconfig /usr/local/lib
• Ensure Emby knows what your library filename is. For me this is the file: /usr/lib/emby-server/bin/ImageMagickSharp.dll.config
  • On the "os=linux" line
  • My newly compiled library name is "libMagickWand-6.Q8.so" however yours may differ
• Restart Emby! Now instead of getting the "Error, Main, ImageMagick not available. Will try next image processor" error, you should see "Info, ImageMagick, ImageMagick version: ImageMagick 6.9.9-8 Q8 x86_64 2017-08-15 http://www.imagemagick.org"

[Luke 37184]

You spoke to tekkb recently?