Getting the CoverArt Plugin Working

[Luke 37010]

I captured what happens on screen. At first coverart seems to be applied and all goes well. When hopping from one folder to another the web app becomes unresponsive: https://onedrive.live.com/redir?resid=18A252CC9E5A2E52!74013&authkey=!AF2zBoE4HivJl3c&ithint=video%2cmp4

 

Probably because the server is being worked very hard to produce the cover art images. Cover Art does consume additional resources so it's not for everyone, but results get saved for re-use to avoid re-creating the same images repeatedly.

[solabc16 379]

Evening

 

Thanks for the video, that helps with understanding what you are experiencing/seeing.

 

This appears similiar to an issue I discussed earlier in this thread, where the UI would 'hang'. (http://emby.media/community/index.php?/topic/32321-getting-the-coverart-plugin-working/?p=309853)

 

As Luke mentioned it will consume additional resources, but I wouldn't expect the quad core atom in the DS1815+ to struggle with this; especially once the images have been initially created.

 

I suspect that something with your CoverArt configuration and/or images is causing the processing to hang, which ultimately ties up all of the http workers.

 

A few next steps...

 

 1) When the UI has reached the stage where it is 'hung', if you close all browsers sessions with Emby and start a new one, does it start responding again (without restarting the server)?

 

 2) Can you restart the server, then navigate around the UI until it 'hangs', at which point shut the browser window and grab the server log and post it here.

 

 3) Are you familiar with Firebug, the web developemnt tool for Firefox (or an equivalent)? By using the request monitor we should be able to identify the problem request, we can then start looking at a solution; this is how we identified and resolved the previous instance of this type of problem.

 

4) Finally, to rule out any unexpected resource demands on the DS1815+, can you load the resource monitor in the DSM UI whilst moving around the Emby WebUI (as per your video) and post a screenshot of the overview tab.

 

If you need any assistance with any of the above, just shout.

 

- James

[Pirlo1966 22]

@ Luke: Yes, it looks like the server is being worked very hard but when I look at CPU and memory usage: MEM stays around 40%, CPU spikes in the beginning to 45-65% range and when emby web app becomes unresponsive  it drops to 1 or 2%... Is that logical?

 

@James: 

1. yes, it starts responding again but just for a minute or two

2. will do

3. will try

4. resources are okay: mem usage is stable around 40% and cpu spikes up to 60/70%

server-63598003887.txt

Edited May 4, 2016 by ehgeahrev

[solabc16 379]

Yes, it looks like the server is being worked very hard but when I look at CPU and memory usage: MEM stays around 40%, CPU spikes in the beginning to 45-65% range and when emby web app becomes unresponsive  it drops to 1 or 2%... Is that logical?

 

Thanks for confirming that detail. Yes, it is logical - in that it supports my theory that some of the requests (as we've seen before) are causing the http request handler to hang, which ultimately results in the 'spinning wheel'; so CPU drops to zero as nothing is happening as a result.

 

Are you able to work through (1), (2) and (3)?

 

- James

[Pirlo1966 22]

1. Was answere I believe or do you need more?

 

2. I attached server log to my previous post.

 

3. will do the firething tomorrow as I am a chrome user and I should go to bed right now :-)

[solabc16 379]

No problem, for some reason half of the details from your post were missing on my screen, I see them now.

 

I'll have a look at the log in the morning.

 

All of the information so far indicates it's a similiar issue to one I've seen before; the tests above demonstrate the server isn't actually failing irrecoverably nor is resource utilation the underlying cause.

 

You can do something similiar in Chrome, if that's your preferred browser.

 

Hit F12 once you have the WebUI loaded and select the network tab. When it starts to slow down/hang, look at the requests that aren't completing (these will be grey horizontal bars), you can then right click on these and grab the request headers. Try to move as slowly through the UI as possible or find a single navigation that causes the slow down/hang, this will reduce the number of requests we need to work through.

 

Select the Img filter, that will make it easier to see the wood from the trees:-

 

 

It will take a bit of iteration, but we will find the one.

 

- James

Edited May 5, 2016 by solabc16

[Pirlo1966 22]

Do not know of this will help. Images treated by coverart started to load and than web app hangs. But all images until then were loaded. Just no new ones.

 

[solabc16 379]

Evening

 

If you hit the [X] next to [Headers], you should be able to see the view with the Status and Timeline present.

 

For now leave the filter on [All], look for the first request that gets stuck with the status [pending].

 

e.g.

 

 

Right click on the request and select 'copy link address' and then try pasting the URL into another tab and see what happens.

 

If it is a problem request, you will see no image returned and the request will also hang indefinitely (like you see in the WebUI).

 

To give you a reference, pick another one [png] that has a status of 200 and do the same, and you will see the image returned.

 

- James

[Pirlo1966 22]

That's cool stuff James! Learning a lot of new things.

 

So okay, I see requests pending. What do you want me to do with these?

 

Right click and copy? As cURL/HAR?

[solabc16 379]

That's good progress, there should be an option at the bottom of the list 'copy link address' - that would be the most useful format for what we're doing here.

 

 

- James

[Pirlo1966 22]

Here you are:

 

http://192.168.1.100:8096/emby/Items/f365221a3da4c9ddeb654d7f042c1f4c/Images/Primary?maxHeight=300&maxWidth=200&tag=0c95964010eac5997919f31cf297d5db&enableImageEnhancers=true&quality=90&accept=webp

 

http://192.168.1.100:8096/emby/Items/b75b8f50445b67b43da8484d04a79881/Images/Primary?maxHeight=300&maxWidth=200&tag=26c7eeadabd7e485378cb4527ad5707b&enableImageEnhancers=true&quality=90&accept=webp

 

http://192.168.1.100:8096/emby/Items/7039e9fb3c4a917adf420a95dcc6a7ea/Images/Primary?maxHeight=300&maxWidth=200&tag=b7a65334697591141597463257312da8&enableImageEnhancers=true&quality=90&accept=webp

 

etc ...  

When I refresh the page there are three pending requests:

 

http://192.168.1.100:8096/web/movies.html?topParentId=5a7b80b8c0929ebc40ab5992985d0b1a

 

http://192.168.1.100:8096/emby/Users/a3c85285beb545e6a873afb8c905ee67/Items/5a7b80b8c0929ebc40ab5992985d0b1a

 

http://192.168.1.100:8096/web/scripts/movies.js?v=3.0.5934.0

[solabc16 379]

Ok, our next step is to identify one that is the cause, rather than being caught up as a result of the problem.

 

To start with make sure you close any previous browser sessions with Emby.

 

Then with the image requests that you've captured in the pending state, work through them by pasting them into the browsers address bar and see if an image is returned. You can do this with the dev-tools (F12) open on the network tab to help see what's going on.

 

A problem request will never return an image and you'll see the request sat pending indefinitely; this should be 100% repeatable.

 

As mentioned above, it would be worth picking one that responds correctly as well, just to get a feel for what you're expecting and to orient yourself.

 

- James

[Abobader 2941]

Good day,

 

Imagemagic at build 7*, do we get that instead of what post here?

 

My best

[solabc16 379]

Evening

 

For now, I would stick with the build from the v6 release train, as there is nothing in particular that would warrant the effort required to move to v7.

 

I will refresh the v6 release in light of the recently disclosed vulnerabilities in ImageMagick; more out of good hygiene that any specific threat at this time.

 

I've starated work on a package for Synology (http://emby.media/community/index.php?/topic/34866-synology-package-in-development/?p=329452). One of the goals is to address the depencies and as far as is practical make Emby install and run as a self contained unit.

 

- James

[Luke 37010]

We have a new installation procedure for Synology users. It's very easy and is now on our website:

 

http://emby.media/nas-server.html

 

All Synology users are recommended to use this going forward (if your model supports it).