erikblues 4 Posted November 25, 2018 Author Share Posted November 25, 2018 What issue do you think needs fixing? We are simply asking ffmpeg to perform a conversion. It is very possible that for your system, the single thread count is the appropriate value. oh sorry @@Luke, I just assumed this is a bug since: Before the latest update I was not facing this issue when transcoding I did not have an upgraded account yet, but I was able to transcode SD movies in realtime now I cant convert an SD movie in 12 hours So I feel like something in the newest version is incompatible with the DS414play,, don't you think so? In another forum post (link below) a user complains about the same problem, but he is using the DS418play, which has more RAM available. In his case, emby server is "just" using more and more RAM, but he still has enough RAM to run the system. But since my DS415play only has 1GB, once the server hits the RAM cap I start getting I/O Wait issues. Since I found a temporary "solution" for now, I think we can close this topic and continue this discussion in this post which is targeting what I think is the real issue: Emby 3.5.3 on NAS not releasing memory Link to comment Share on other sites More sharing options...
solabc16 379 Posted November 25, 2018 Share Posted November 25, 2018 Hello @erikblues I will look at this further next week, but just to avoid any ambiguity for other readers of the thread, this issue and the one you reference are different. One is a suspected memory leak in the runtime environment, this is system resource starvation due to memory consumption by FFmpeg. Had you previously tried using this experimantal feature (https://emby.media/community/index.php?/topic/43282-hw-transcoding-on-evansport-ds415playds214play-machines/?hl=ds415play) before upgrading? Best - James Link to comment Share on other sites More sharing options...
erikblues 4 Posted November 25, 2018 Author Share Posted November 25, 2018 Hi @@solabc16, One is a suspected memory leak in the runtime environment, this is system resource starvation due to memory consumption by FFmpeg. Good to know, I thought they were related. Thanks! Had you previously tried using this experimantal feature (https://emby.media/community/index.php?/topic/43282-hw-transcoding-on-evansport-ds415playds214play-machines/?hl=ds415play) before upgrading? No, I was using the normal installation with only 3-4 plugins installed (as I have it now). I also upgraded my account to a paid Emby account, so before this version I was only doing "real time" transcoding since file conversion is unavailable in the free version. But if I was able to stream SD movies in realtime (usually without problems), then I think the same movie transcoded should happen in less than 12 hours. I also disabled all possible other apps that are installed on the NAS (download station, log center etc), to free up some RAM, but it is still not enough for what the NAS is consuming since the update as you can see in this graph of memory consumption in the last year (note, before the update the download station, log center, photo station and other apps were also running in the background and are now disabled. still, RAM usage is capping at 80%, which is when I/O Wait overflow starts): Do you think the DS415play is to old to run Emby? Link to comment Share on other sites More sharing options...
solabc16 379 Posted November 25, 2018 Share Posted November 25, 2018 Hi @@erikblues There's a lot of end users successfully running on this platform, so I definitely wouldn't put it in the category of 'too old'. Of course, the experience will depend on what features you have enabled and how you are using it. As with many software applications, not all hardware platforms will be capable of delivering all of the features at an acceptable level of performance. When you mention 'I was able to stream SD movies in realtime' above, were these transcoding or direct playing? Best - James 1 Link to comment Share on other sites More sharing options...
erikblues 4 Posted November 25, 2018 Author Share Posted November 25, 2018 When you mention 'I was able to stream SD movies in realtime' above, were these transcoding or direct playing? Hi James, They were transcoding, and sometimes it was unable to transcode them fast enough. Depending on the file, I would have to let it load for a while before playing and it would stay stuck again near the end (720-1080, 24min episode). That is why I upgraded, so I would be able to convert the files before playing them. But now, a file which I was able to transcode in “almost real-time” in 30-60mins now wasn’t finishing conversion in 12 hours. Now that I changed it to “use one CPU thread” it is working. Slower, but it works. About 3-4 hours for the same file. I hope this information is useful somehow. Thanks for all your effort guys. It’s really appreciated! Link to comment Share on other sites More sharing options...
solabc16 379 Posted November 25, 2018 Share Posted November 25, 2018 Hello @@erikblues Thanks for the information, that's useful. I wouldn't expect the two different scenarios to use the same FFmpeg command line, so this is the most likely cause of the differing behaviour. With your system set to “use one CPU thread", if you sort the processes by name in resource monitor, can you take a screenshot of the FFmpeg processes (like before) with a conversion running. Best - James Link to comment Share on other sites More sharing options...
erikblues 4 Posted November 26, 2018 Author Share Posted November 26, 2018 Sure: Here also the list of mono-sgen processes (because these are also taking up so much RAM). Link to comment Share on other sites More sharing options...
solabc16 379 Posted November 26, 2018 Share Posted November 26, 2018 Thanks @@erikblues This memory is used across all of the listed processes - they are not using 91.6MB each. The same with FFmpeg, in this specific case. A different analysis would be needed if you had two or more FFmpeg processes running. What you are seeing is the threads that are part of the process. These look ok and I wouldn't say 'taking up so much RAM'. The DS415play is a dual core, four thread machine - this is why you are seeing the FFmpeg process running at a consistent ~25% CPU. This relates to the configuration setting "use one CPU thread” you made. Best - James 1 Link to comment Share on other sites More sharing options...
erikblues 4 Posted November 26, 2018 Author Share Posted November 26, 2018 (edited) Thanks for clearing that up @solabc16 Since today the server is working MUCH better, even though I changed nothing in the settings. Look at this 24h log: Notice how between 12 and 14h the server went back to normal and is now handling the same conversion list (it has been running since yesterday) much better. RAM usage dropped during the same time, and I/O Wait went back to normal. This is the way the server was working before the update and is what I mean when I say that something isn't acting right since the update. I generated a new log right away and hope it gives you some insight on this: sendlogs_Weitenau_synology_evansport_415play_20181126T181631UTC.tgz Edited November 26, 2018 by erikblues Link to comment Share on other sites More sharing options...
erikblues 4 Posted November 30, 2018 Author Share Posted November 30, 2018 After 2 days running fine converting media, it sometimes spiked up but seemed to run smoothly most of the time. But today for some reason it TOTALLY spiked again. Wasn't able to do "sudo ./sendlogs" because it gave me "ERROR: Failed to create the log archieve." I had to stop the conversion to be able to send the log. Any idea what is causing this? Maybe the size of the file being converted? Log file: sendlogs_Weitenau_synology_evansport_415play_20181130T205403UTC.tgz Link to comment Share on other sites More sharing options...
solabc16 379 Posted November 30, 2018 Share Posted November 30, 2018 Hello @@erikblues Thanks for the update and the logs, I'll take a look at those in the morning. I've fixed the issue that causes the ""ERROR: Failed to create the log archive.", that will be in the next release. From what I've looked at so far, the variable at play here is the file itself being transcoded; anything else I believe to be coincidental. This will provide an additional data point, that should help us understand it better. Best - James 1 Link to comment Share on other sites More sharing options...
erikblues 4 Posted November 30, 2018 Author Share Posted November 30, 2018 @@solabc16 I've fixed the issue that causes the ""ERROR: Failed to create the log archive.", that will be in the next release. From what I've looked at so far, the variable at play here is the file itself being transcoded; anything else I believe to be coincidental. This will provide an additional data point, that should help us understand it better. That makes sense. I think now is time I should stop sending you logs and wait for the next release but please don't hesitate to let me know if I can send you anything else that can help. And thanks for correcting that log error James Link to comment Share on other sites More sharing options...
erikblues 4 Posted December 2, 2018 Author Share Posted December 2, 2018 Other file (much bigger file), 2 threads, running on full CPU for 24h. Had some I/O when I tried to use the NAS while conversion was happening. After that is took a while to stabalize again. Maybe it helps: sendlogs_Weitenau_synology_evansport_415play_20181202T153932UTC.tgz 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