jeffu231 1 Posted August 3, 2019 Share Posted August 3, 2019 I am running the latest release server on Ubuntu 18.04.2 LTS. I am seeing high cpu usage on the embyserver process while direct streaming live tv from an HD Homerun. Both audio and video indicate they are being direct streamed. Top shows around 80% on a modern 4 core Intel machine. The ffmpeg process is very low around 1-2%. I would expect the repacking from MPEGTS to HLS to be very low cpu usage. I don't recall seeing this high usage before upgrading to 4.2. Any thoughts? Jeff Link to comment Share on other sites More sharing options...
Luke 36884 Posted August 3, 2019 Share Posted August 3, 2019 Hi there, let's look at an example. Please attach the information requested in how to report a problem. thanks ! Link to comment Share on other sites More sharing options...
jeffu231 1 Posted August 3, 2019 Author Share Posted August 3, 2019 Here are the logs and a screen capture of top showing the cpu usage of the emby processes. I was watching a live TV feed that was direct streaming. Let me know if you need anything else. Jeff embyserver.txt ffmpeg-directstream-615c8531-3f8d-4500-b6d6-e653e6cbf650_1.txt Link to comment Share on other sites More sharing options...
softworkz 3301 Posted August 3, 2019 Share Posted August 3, 2019 Does it always happen with any stream or sometimes only or only with certain streams? Link to comment Share on other sites More sharing options...
softworkz 3301 Posted August 3, 2019 Share Posted August 3, 2019 Could you please activate debug logging, restart the server, reproduce (only once) and post the log? Thanks Link to comment Share on other sites More sharing options...
jeffu231 1 Posted August 3, 2019 Author Share Posted August 3, 2019 720 and 1080 content are about the same. If I find a SD broadcast, then the CPU drops to about 15%. I stopped watching last night and when I checked today to do this test the embyserver was stuck with 90-100% CPU. I restarted it and it dropped back down. The Dashboard did not show any activity and I don't have any outside users. One thing I did notice is that every time I restart Emby since the update, after the restart the Dashboard comes up and says restart the server to finish the updates. I have restarted Emby numerous times and the actual server as well. Not sure if this is some other bug or a indicator of what might be wrong. Here are the debug logs for a 1080 broadcast. I only grabbed a few minutes. Let me know if you need more. Thanks Jeff embyserver_debug.txt ffmpeg-directstream-05e9209b-c875-42cc-a72f-8ac4d7fd0653_1.txt Link to comment Share on other sites More sharing options...
jeffu231 1 Posted August 3, 2019 Author Share Posted August 3, 2019 Here is that restart message for completeness. If I refresh the browser after it appears, it goes away. This happens everytiem I restart the Emby server from the web interface. Link to comment Share on other sites More sharing options...
softworkz 3301 Posted August 4, 2019 Share Posted August 4, 2019 Thanks for the new log. The only unusual behavior I could see is that the Roku is retrieving HLS segments as 1 MB chunks via range requests. Could you please try to do a TV recording without watching watching live TV from a browser client ...and check if you're seeing the same CPU usage in these cases? Thanks Link to comment Share on other sites More sharing options...
jeffu231 1 Posted August 4, 2019 Author Share Posted August 4, 2019 The embyserver process runs similarly high while recording. There is no ffmpeg process while recording. No viewing or any other activities were occurring at the same time. Watching live tv from the web interface produces similar high cpu on the embyserver process. The ffmpeg process is a higher than it is when viewing on the Roku. It runs about 25%. Pausing the live stream does not change the CPU rate. I suspect this is because it is in essence recording it for time shifting, so maybe that points to the recording process with the information from the recording test. I can watch a completed recording and the cpu use on the embyserver process is very low while the ffmpeg runs higher in bursts as it transcodes ahead. Jeff Link to comment Share on other sites More sharing options...
Luke 36884 Posted August 4, 2019 Share Posted August 4, 2019 Would you mind posting the server log from the recording just so that we can try to rule out any other possible causes? Thanks. Link to comment Share on other sites More sharing options...
jeffu231 1 Posted August 4, 2019 Author Share Posted August 4, 2019 I turned on debugging, restarted the server and then made the recording for a few minutes and then stopped it. I included a capture of top a minute or so into the recording for cpu reference. embyserver-recording.txt Link to comment Share on other sites More sharing options...
Luke 36884 Posted August 4, 2019 Share Posted August 4, 2019 Thanks. Link to comment Share on other sites More sharing options...
softworkz 3301 Posted August 7, 2019 Share Posted August 7, 2019 @@jeffu231 - Sorry for the delay. I looked at your logfile and while the video recording was running there were more than a thousand log entries about library scanning. Would you be able to repeat it without any library scan running at the same time, so that we can sure it isn't caused by other factors? Thanks Link to comment Share on other sites More sharing options...
jeffu231 1 Posted August 7, 2019 Author Share Posted August 7, 2019 Here is a another attempt. Hopefully nothing else was running. embyserver-recording.txt Link to comment Share on other sites More sharing options...
jeffu231 1 Posted August 8, 2019 Author Share Posted August 8, 2019 Here is another one that I let go a little longer. It has about 5 minutes of recording time. embyserver-recording.txt Link to comment Share on other sites More sharing options...
softworkz 3301 Posted August 8, 2019 Share Posted August 8, 2019 Thank you very much. None of those log files are showing anything unusual. I'm afraid that there's no easy solution for this. Do you have a single IPTV provider or do you have a second one to compare? No problem though if you don't have. The next step is that we'll create a beta build that allows switching off the built-in timestamp correction. This will allow us to confirm that the CPU load is caused by the timestamp correction procedures and to create an unmodified recording of the raw iptv stream which we can use to reproduce processing that happens on your side Link to comment Share on other sites More sharing options...
jeffu231 1 Posted August 8, 2019 Author Share Posted August 8, 2019 Thank you very much. None of those log files are showing anything unusual. I'm afraid that there's no easy solution for this. Do you have a single IPTV provider or do you have a second one to compare? No problem though if you don't have. The next step is that we'll create a beta build that allows switching off the built-in timestamp correction. This will allow us to confirm that the CPU load is caused by the timestamp correction procedures and to create an unmodified recording of the raw iptv stream which we can use to reproduce processing that happens on your side I only have the one HD Homerun device to pull from. I was trying to figure out how I could attach a profiler to the process and capture what is going on. I have a lot of .NET experience, but I have never applied it to Mono/Linux, so I am not sure what the best tools are to do that. If it were a windows box, I would load up one of the profilers I have and take a look at it. I am open to helping however I can to chase it down. Jeff Link to comment Share on other sites More sharing options...
jeffu231 1 Posted August 9, 2019 Author Share Posted August 9, 2019 FYI, I upgraded to 4.2.1 and it did not change it. I could not find a change log for what was in that update. Link to comment Share on other sites More sharing options...
Luke 36884 Posted August 9, 2019 Share Posted August 9, 2019 I could not find a change log for what was in that update. Have you explored your server dashboard? Link to comment Share on other sites More sharing options...
jeffu231 1 Posted August 9, 2019 Author Share Posted August 9, 2019 I have, but maybe I am looking in the wrong place. The Latest news has info about an IOS update on 8/7 and the 4.2.0 update on 7/23. Nothing about 4.2.1. The you have a pending update just took me to the download site. Is there someplace else I should be looking? Link to comment Share on other sites More sharing options...
Luke 36884 Posted August 9, 2019 Share Posted August 9, 2019 Did you try clicking the version number on the server dashboard? Link to comment Share on other sites More sharing options...
jeffu231 1 Posted August 9, 2019 Author Share Posted August 9, 2019 I had not tried that, but now I know. Thanks Jeff 1 Link to comment Share on other sites More sharing options...
Luke 36884 Posted August 9, 2019 Share Posted August 9, 2019 Anyway, this won't be changed in 4.2.1 as we don't know the reason for this yet. In the next beta server I will be adding a debug option for you to try to help us narrow it down. Thanks. Link to comment Share on other sites More sharing options...
jeffu231 1 Posted August 9, 2019 Author Share Posted August 9, 2019 I didn't really expect it to either, but I was just clarifying that the new version did not magically change anything. I will await further instructions on how I can help track it down. Jeff Link to comment Share on other sites More sharing options...
softworkz 3301 Posted September 3, 2019 Share Posted September 3, 2019 @@jeffu231 - This should be fixed now. Could you please retry with the latest beta? 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