hurricanehrndz 149 Posted February 19, 2017 Share Posted February 19, 2017 Smart:) Docker is a really nice solution for things like that, until you need some firewalling in front and you don't have a designated appliance in front of it. I was forced to ditch the solution, because securing it with iptables is just... ugh, no good solution.. You can secure socket with any other wrapper service for iptables. Personally I use firewalld, but any other service will work as well. Sent from my ONEPLUS A3000 using Tapatalk Link to comment Share on other sites More sharing options...
bungee91 98 Posted March 23, 2017 Share Posted March 23, 2017 I'm trying to troubleshoot a transcoding issue that seems to be only affecting the Android mobile version of Emby. Luke recommended trying ffmpeg 3.2.3, or the git build. Did a quick search here and was wondering if the following command would still apply to update this within the container? Also, if I wanted to test with 3.2.3 (I believe currently the beta docker is using 3.2.4), could you tell me the right link to substitute in this command to test with that? Thanks! For the people having troubles with ffmpeg please execute the following command to update ffmpeg within the container. docker exec -it emby-server bash -c 'zypper --non-interactive in curl; \ ⏎ curl -sL https://johnvansickle.com/ffmpeg/builds/ffmpeg-git-64bit-static.tar.xz | \ tar -C /bin --extract -J --wildcards "*/ffmpeg" --wildcards "*/ffprobe" --strip-components=1' Link to comment Share on other sites More sharing options...
hurricanehrndz 149 Posted March 23, 2017 Share Posted March 23, 2017 Should work only way to know for sure is to run it, it is a docker container after all so it's not like changes are permanent Sent from my ONEPLUS A3000 using Tapatalk Link to comment Share on other sites More sharing options...
bungee91 98 Posted March 23, 2017 Share Posted March 23, 2017 Good deal, thanks for confirming.. I get it.. Will test and report back if it resolves the issue I'm having. Link to comment Share on other sites More sharing options...
TrainAss 22 Posted March 23, 2017 Share Posted March 23, 2017 (edited) Just ran the command, and now I'm updating Emby Server. I'll advise shortly. One thing I noticed is that some stuff was having issues playing, either stuttering or would freeze up part way; sometimes not even play. Not sure what was causing it though. Edit: I should clarify that the locking up and freezing was BEFORE I ran the command. Edited March 24, 2017 by TrainAss Link to comment Share on other sites More sharing options...
kmarq13 5 Posted March 24, 2017 Share Posted March 24, 2017 (edited) Just ran the command, and now I'm updating Emby Server. I'll advise shortly. One thing I noticed is that some stuff was having issues playing, either stuttering or would freeze up part way; sometimes not even play. Not sure what was causing it though. Edit: I should clarify that the locking up and freezing was BEFORE I ran the command. Any update? I'm having issues currently with the docker version and Android mobile. It just sits with a black screen. Answered this myself. Just ran the docker ffmpeg update and now transcoding is working beautifully again. Edited March 24, 2017 by kmarq13 Link to comment Share on other sites More sharing options...
TrainAss 22 Posted March 25, 2017 Share Posted March 25, 2017 Any update? I'm having issues currently with the docker version and Android mobile. It just sits with a black screen. Answered this myself. Just ran the docker ffmpeg update and now transcoding is working beautifully again. Sorry, yes, everything is working great. Link to comment Share on other sites More sharing options...
Luke 37095 Posted March 25, 2017 Author Share Posted March 25, 2017 Thanks for the feedback Link to comment Share on other sites More sharing options...
bungee91 98 Posted March 25, 2017 Share Posted March 25, 2017 (edited) Finally was able to test this, all is working as expected now. Knowing this, will updates to the container make changes to ffmpeg and require this to be ran again? Also, since this fixes the issues some are having with Android mobile (however could cause issues in other ways), will this container be updated to include a different version of ffmpeg (than what is included by default now) so that this is resolved for good.? Edited March 25, 2017 by bungee91 Link to comment Share on other sites More sharing options...
hurricanehrndz 149 Posted March 25, 2017 Share Posted March 25, 2017 We could, I update ffmpeg on Luke's recommendations. If @@Luke says it is a go, I will update it. Sent from my ONEPLUS A3000 using Tapatalk 1 Link to comment Share on other sites More sharing options...
Luke 37095 Posted March 25, 2017 Author Share Posted March 25, 2017 @@bungee91, what version did you update to? Link to comment Share on other sites More sharing options...
bungee91 98 Posted March 25, 2017 Share Posted March 25, 2017 @@Luke, most recent git version ~2 hours ago. Comes up as N-83692-gb8a7dcbde2-static Link to comment Share on other sites More sharing options...
yotamN 1 Posted March 26, 2017 Share Posted March 26, 2017 When I installed Emby with Docker I got the message: grep: write error: Broken pipe Is that supposed to happen? Link to comment Share on other sites More sharing options...
hurricanehrndz 149 Posted March 26, 2017 Share Posted March 26, 2017 Nope, it is not suppose to happen. How are you installing it. Sent from my ONEPLUS A3000 using Tapatalk Link to comment Share on other sites More sharing options...
skurvy_pirate 2 Posted March 28, 2017 Share Posted March 28, 2017 Is there a reason that ffmpeg was updated to 3.2.4 for the Docker container? It seems (as noted above and in the mobile thread) to cause issues with the Android mobile app. Does the docker image just include the "recommended" version? And if so, wouldn't other servers (Windows, NAS, etc) experience the same issues for the Android client? I am just wondering because it seemed like there were very few people that had this issue. Link to comment Share on other sites More sharing options...
hurricanehrndz 149 Posted March 28, 2017 Share Posted March 28, 2017 (edited) Docker was updated on dev team's recommendation. For other installsz users have a lot of control over the ffmpeg version and emby by default will not auto update it Sent from my ONEPLUS A3000 using Tapatalk Edited March 28, 2017 by hurricanehrndz Link to comment Share on other sites More sharing options...
simonk83 7 Posted March 28, 2017 Share Posted March 28, 2017 (edited) Hi all, I know this has come up before, but I guess I'm bringing it up again I run this in Docker (obviously) on a Synology DS1512+. I have it set to update quickly when Radarr or Sonarr push something, and that works fine (it just scans the new file), but I also do a full scan once a day, just in case. This scan generally takes about 20 minutes, but it can take up to an hour for some reason. This is for ~600 movies and ~5000 episodes, all stored on the same NAS, all in their own individual folders (as appose to all movies bunged unceremoniously into one folder). I don't use a music library. I have "Save artwork and metadata into media folders" unchecked, so everything is stored in the metadata folder in the Docker folder (I used to have all metadata stored with the individual files, but I changed it to this as I heard it would speed up scans (it didn't). I've read some of the previous threads comparing the scan to other solutions (watchdog for example), and it is true that those solutions take seconds rather than a full hour with Emby. So, is there anything I can do here to speed this up? Is it due to running in Docker? Is it a consequence of my setup, and if so what would be a more efficient option? Is a new scan engine being worked on? Edited March 28, 2017 by simonk83 Link to comment Share on other sites More sharing options...
skurvy_pirate 2 Posted March 28, 2017 Share Posted March 28, 2017 Hi all, I know this has come up before, but I guess I'm bringing it up again I run this in Docker (obviously) on a Synology DS1512+. I have it set to update quickly when Radarr or Sonarr push something, and that works fine (it just scans the new file), but I also do a full scan once a day, just in case. This scan generally takes about 20 minutes, but it can take up to an hour for some reason. This is for ~600 movies and ~5000 episodes, all stored on the same NAS, all in their own individual folders (as appose to all movies bunged unceremoniously into one folder). I don't use a music library. I have "Save artwork and metadata into media folders" unchecked, so everything is stored in the metadata folder in the Docker folder (I used to have all metadata stored with the individual files, but I changed it to this as I heard it would speed up scans (it didn't). I've read some of the previous threads comparing the scan to other solutions (watchdog for example), and it is true that those solutions take seconds rather than a full hour with Emby. So, is there anything I can do here to speed this up? Is it due to running in Docker? Is it a consequence of my setup, and if so what would be a more efficient option? Is a new scan engine being worked on? I am not sure I understand what you are asking. Do you have "Enable Real Time Monitoring" checked for your Library folders in Emby? If so, new stuff should just show up like you mentioned. The daily scan won't be adding stuff in most cases so it shouldn't really matter how long it takes, but I think it might do other things as well. But an hour does seem way too long, I have similar number of items and my last scan says 2 minutes. The only time it takes that long is when first scanning everything or maybe moving files around. 1 Link to comment Share on other sites More sharing options...
simonk83 7 Posted March 28, 2017 Share Posted March 28, 2017 I am not sure I understand what you are asking. But an hour does seem way too long, I have similar number of items and my last scan says 2 minutes. The only time it takes that long is when first scanning everything or maybe moving files around. I guess I'm asking why is it taking an hour when others, yourself included, have it complete in a couple of minutes Is it my hardware (ram, CPU?) Is it my setup? Link to comment Share on other sites More sharing options...
skurvy_pirate 2 Posted March 28, 2017 Share Posted March 28, 2017 Yeah that is odd. Does it always take that long? It would be interesting to see your server log after a scan to see what it is doing and which operations are taking the longest. Looking up your NAS specs it says it is a dual core with only 1GB of RAM. That seems pretty low so it might be possible your hardware is the limiting factor here. Also depends what else you have running on your NAS. Link to comment Share on other sites More sharing options...
simonk83 7 Posted March 29, 2017 Share Posted March 29, 2017 Yeah that is odd. Does it always take that long? It would be interesting to see your server log after a scan to see what it is doing and which operations are taking the longest. Looking up your NAS specs it says it is a dual core with only 1GB of RAM. That seems pretty low so it might be possible your hardware is the limiting factor here. Also depends what else you have running on your NAS. I'm happy to kick off a manual scan and upload the log. I've actually got 3GB ram in the NAS, but still not great. I have a bunch of other Docker containers running on it as well (Sonarr, Radarr, nzbget, Ombi, Organizr, Jackett, Unifi Video) so ram is certainly an issue. Probably going to upgrade to a new NAS with 16GB ram next month when they're released but not 100% sure that'll help. I figured if Emby is running on the same box as the files (albeit in a container) it ought to be fairly quick, but I'm missing something obviously. What are you running it on? Link to comment Share on other sites More sharing options...
skurvy_pirate 2 Posted March 29, 2017 Share Posted March 29, 2017 I build a Mini-ITX form factor server box with a Skylake i7 and 32GB of RAM. Using it for other stuff as well, but it very underutilized right now. With all that running on your box I am guessing CPU is also an issue. Can you check your "normal" CPU usage and also when it is scanning? Uploading the logs here after your next scan would be useful too. Link to comment Share on other sites More sharing options...
simonk83 7 Posted March 29, 2017 Share Posted March 29, 2017 Normal CPU is 2-4%. When scanning it's around 10-13% so that seems fine. I'll grab the log when it's finished running Link to comment Share on other sites More sharing options...
simonk83 7 Posted March 29, 2017 Share Posted March 29, 2017 Ok, here we go! https://gist.githubusercontent.com/simonk83/841d3b6d99ac5407d16bccf4f0a681e5/raw/13178765649134f2b1969a8748a2b7ee2d920a97/gistfile1.txt Link to comment Share on other sites More sharing options...
Luke 37095 Posted March 29, 2017 Author 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. 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