simonk83 7 Posted March 29, 2017 Share Posted March 29, 2017 @@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? Link to comment Share on other sites More sharing options...
Luke 37095 Posted March 29, 2017 Author Share Posted March 29, 2017 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. Link to comment Share on other sites More sharing options...
simonk83 7 Posted March 29, 2017 Share Posted March 29, 2017 (edited) 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 Link to comment Share on other sites More sharing options...
simonk83 7 Posted March 29, 2017 Share Posted March 29, 2017 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? Link to comment Share on other sites More sharing options...
bungee91 98 Posted March 29, 2017 Share Posted March 29, 2017 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? Link to comment Share on other sites More sharing options...
hurricanehrndz 149 Posted March 29, 2017 Share Posted March 29, 2017 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 Link to comment Share on other sites More sharing options...
Luke 37095 Posted March 29, 2017 Author Share Posted March 29, 2017 I would just update normally and use the default. Link to comment Share on other sites More sharing options...
bungee91 98 Posted March 29, 2017 Share Posted March 29, 2017 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! Link to comment Share on other sites More sharing options...
hurricanehrndz 149 Posted March 29, 2017 Share Posted March 29, 2017 Container has not been updated with new ffmpeg yet. I will later today. Sent from my ONEPLUS A3000 using Tapatalk Link to comment Share on other sites More sharing options...
skurvy_pirate 2 Posted March 29, 2017 Share Posted March 29, 2017 @@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. Link to comment Share on other sites More sharing options...
Luke 37095 Posted March 29, 2017 Author Share Posted March 29, 2017 Is it the exact same version you had before? Link to comment Share on other sites More sharing options...
hurricanehrndz 149 Posted March 29, 2017 Share Posted March 29, 2017 New build has been trigger with the latest git version of ffmpeg. Link to comment Share on other sites More sharing options...
bungee91 98 Posted March 29, 2017 Share Posted March 29, 2017 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. Link to comment Share on other sites More sharing options...
Luke 37095 Posted March 29, 2017 Author Share Posted March 29, 2017 Thanks for the feedback ! Link to comment Share on other sites More sharing options...
simonk83 7 Posted March 29, 2017 Share Posted March 29, 2017 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... Link to comment Share on other sites More sharing options...
anderbytes 139 Posted March 29, 2017 Share Posted March 29, 2017 (edited) 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 Link to comment Share on other sites More sharing options...
simonk83 7 Posted March 30, 2017 Share Posted March 30, 2017 First scan today - 23 minutes... Scheduled scan ran and took 47 minutes, so there's definitely something weird going on. Link to comment Share on other sites More sharing options...
skurvy_pirate 2 Posted March 30, 2017 Share Posted March 30, 2017 Scheduled scan ran and took 47 minutes, so there's definitely something weird going on. Do you have the log from it? Link to comment Share on other sites More sharing options...
simonk83 7 Posted March 30, 2017 Share Posted March 30, 2017 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. Link to comment Share on other sites More sharing options...
skurvy_pirate 2 Posted March 31, 2017 Share Posted March 31, 2017 Latest docker image still has ffmpeg 3.2.4-static. Link to comment Share on other sites More sharing options...
hurricanehrndz 149 Posted March 31, 2017 Share Posted March 31, 2017 Ah.. thanks for the update Sent from my ONEPLUS A3000 using Tapatalk Link to comment Share on other sites More sharing options...
hurricanehrndz 149 Posted March 31, 2017 Share Posted March 31, 2017 I will look into it Sent from my ONEPLUS A3000 using Tapatalk Link to comment Share on other sites More sharing options...
yotamN 1 Posted March 31, 2017 Share Posted March 31, 2017 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. Link to comment Share on other sites More sharing options...
simonk83 7 Posted April 3, 2017 Share Posted April 3, 2017 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. Link to comment Share on other sites More sharing options...
hoppel118 37 Posted April 3, 2017 Share Posted April 3, 2017 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 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