Docker

[simonk83 7]

@@simonk83 - two things. First try removing the kodi sync plugin. It may impact library scan times.

 

Second, throughout the time of the library scan, something is hammering your server with requests for database lookups. Here is an example:

HTTP GET http://192.168.1.7:8096/emby/users/87c4757983184d61b19856c9782527d3/items/5749138a2ab3957344f82e085e720f12. UserAgent: Rest Sharp/105.2.3.0

I don't know what that is, because none of the Emby apps are using RestSharp. So whatever software is doing that, try shutting it down.

 

Hmm, I wonder if it's another docker container.   Is there an easy way to track it down?

[Luke 42077]

You should know what other software you have given access to your Emby Server. The requests it is making require authentication which means you had to have provided that. I'm going to go out on a limb here and guess that you should be able to figure it out.

[simonk83 7]

Ah you know what, I bet it's Ombi...

 

I'll shut that down and I'll disable the Kodi sync plugin and run another scan.   To be honest though it was taking this long before I installed Ombi so not sure it's that.

Edited March 29, 2017 by simonk83

[simonk83 7]

Ok, well that does seem to have helped a bit.   I've run the scan three times, about 30 mins apart.

 

Scan 1:  15 mins

Scan 2:  16 mins

Scan 3:  17 mins...

 

I'll be interested to try another scan or three tomorrow to see if things continue to degrade.   To be honest I have noticed a good amount of slowdown after the container has been running a while, I just haven't looked into it too much until now.

 

Is anyone else seeing similar behaviour?

[bungee91 133]

Wondering if taking a normal update for this container will revert the ffmpeg I updated to, or not?

If it will not, will I be stuck on the version I updated to unless I manually perform or delete/re-install the container?

[hurricanehrndz 149]

Changes on containers never persist unless the changes occur on mounted volumes. So it means you can permanently control the version of ffmpeg by mounting a host binary.

 

Sent from my ONEPLUS A3000 using Tapatalk

[Luke 42077]

I would just update normally and use the default.

[bungee91 133]

I'm still confused, bear with me.. 

 

Changes on containers never persist unless the changes occur on mounted volumes. So it means you can permanently control the version of ffmpeg by mounting a host binary.

Sent from my ONEPLUS A3000 using Tapatalk

 

I think this means: It will replace the one I manually updated to on update, correct? (unless I mount it externally, right?).

 

I would just update normally and use the default.

 

I think this means: You've fixed this issue, and have updated/replaced the problematic ffmpeg, and if I perform the normal update I'll be back to "default", right?

 

 You guys rock, thanks!

[hurricanehrndz 149]

Container has not been updated with new ffmpeg yet. I will later today.

 

Sent from my ONEPLUS A3000 using Tapatalk

[skurvy_pirate 2]

@@bungee91 if you update your container you will lose any changes you have made. This will also happen if you stop and restart the container. If you have upgraded your ffmpeg version, you will need to run the update command again after upgrading/restarting.

 

As hurricanehrndz said, you can have it persist if you install the version you want on your docker host and then mount that path in your container. Then you would just point Emby to that location for ffmpeg. 

 

But no, the issue is not fixed. Latest is still using 3.2.4 which has the problem.

[Luke 42077]

Is it the exact same version you had before?

[hurricanehrndz 149]

New build has been trigger with the latest git version of ffmpeg. 

[bungee91 133]

Thanks for the explanation(s), I did take the update and can confirm the same issue as before was present (not the newest build that is mentioned above this post, but whatever is in 3.2.9.3 beta).

Reapplied the ffmpeg update to git version, all back to working.

 

Stop/starting the container for me doesn't effect the version of ffmpeg, but updating the container certainly did.

Glad this will be resolved within the build soon.

[Luke 42077]

Thanks for the feedback !

[simonk83 7]

Ok, well that does seem to have helped a bit.   I've run the scan three times, about 30 mins apart.

 

Scan 1:  15 mins

Scan 2:  16 mins

Scan 3:  17 mins...

 

I'll be interested to try another scan or three tomorrow to see if things continue to degrade.   To be honest I have noticed a good amount of slowdown after the container has been running a while, I just haven't looked into it too much until now.

 

Is anyone else seeing similar behaviour?

 

First scan today - 23 minutes...

[anderbytes 141]

New build has been trigger with the latest git version of ffmpeg. 

 

Also on latest stable? I tried using the 3.2.9 image and some error is ocurring when trying to download ffmpeg from embydata.com , when server starts

 

UPDATE: The last time I restarted the container it managed to resolve the download. Crazy.

Edited March 29, 2017 by anderbytes

[simonk83 7]

First scan today - 23 minutes...

Scheduled scan ran and took 47 minutes, so there's definitely something weird going on.

[skurvy_pirate 2]

Scheduled scan ran and took 47 minutes, so there's definitely something weird going on.

 

Do you have the log from it?

[simonk83 7]

Do you have the log from it?

 

I don't unfortunately, I'll grab today's.

 

To be honest I think I might just ditch the Emby docker install on the NAS and repurpose a Mac Mini for the task.  I'm thinking of putting Linux on the Mini and using it for Emby, an NVR, and maybe pfsense in a VM.   I'd like to be able to let family members use Emby remotely at some point so I'll need transcoding, and hence a better CPU anyway.

[skurvy_pirate 2]

Latest docker image still has ffmpeg 3.2.4-static.

[hurricanehrndz 149]

Ah.. thanks for the update

 

Sent from my ONEPLUS A3000 using Tapatalk

[hurricanehrndz 149]

I will look into it

 

Sent from my ONEPLUS A3000 using Tapatalk

[yotamN 1]

Nope, it is not suppose to happen. How are you installing it.

 

Sent from my ONEPLUS A3000 using Tapatalk

 

I copied the command from the instructions.

I have Docker version 17.03.1-ce, build c6d412e if that matters.

I also notice that Hebrew subtitles doesn't work for me (it work when I wasn't using Docker) but that could be unrelated.

[simonk83 7]

I don't unfortunately, I'll grab today's.

 

To be honest I think I might just ditch the Emby docker install on the NAS and repurpose a Mac Mini for the task.  I'm thinking of putting Linux on the Mini and using it for Emby, an NVR, and maybe pfsense in a VM.   I'd like to be able to let family members use Emby remotely at some point so I'll need transcoding, and hence a better CPU anyway.

 

Ok, just to close this out I ended up installing ProxMox on a Mac Mini. I put Windows Server 2012 R2 in a VM and installed Emby in there.  The scan now takes around 4.5 minutes so that's fixed that.  I expect it was just the NAS struggling.

[hoppel118 37]

Do you use your Windows Server only for emby?

 

If so, you could decide to build a Linux-Container under your proxmox host and install emby into this LXC. Maybe an alternative to the fat Windows Server...

 

Greetings Hoppel