ebr 14960 Posted September 6, 2017 Share Posted September 6, 2017 So... Everyone with this issue is running as a service...? Link to comment Share on other sites More sharing options...
jnheinz 17 Posted September 6, 2017 Share Posted September 6, 2017 (edited) @@TheHwyman - Excellent write-up. Very similar environment & experience to mine. It was in June that the problems began; however, I don't install Windows updates as frequently on certain boxes, so I don't think mine ever received any .NET framework updates in 2017. I also have mostly Emby for Kodi clients. I actually moved my Emby environment to Ubuntu Server 16.04 LTS as a trial. I think mono has its own issues, but they are different. I still have the Emby Server service running on the old Server 2012 R2 installation with no libraries or tuners. It is still leaking memory slowly with no libraries. Edited September 6, 2017 by jnheinz 1 Link to comment Share on other sites More sharing options...
TylerV76 84 Posted September 6, 2017 Share Posted September 6, 2017 So... Everyone with this issue is running as a service...? Ive ran it both as a server and as an app and the same problem has happened both ways. So far if I I dont let it transcode an active recording I havent gone above 300MB. Granted Ive only been testing that a little last night and a couple hours today. Link to comment Share on other sites More sharing options...
ebr 14960 Posted September 6, 2017 Share Posted September 6, 2017 Ive ran it both as a server and as an app and the same problem has happened both ways. Are you sure of that? Keep in mind that Emby consuming memory is not necessarily a problem. It is about how much and if it never gets released. Can you run as both a service and regular app and reproduce the exact same memory profile? Link to comment Share on other sites More sharing options...
TylerV76 84 Posted September 6, 2017 Share Posted September 6, 2017 (edited) Are you sure of that? Keep in mind that Emby consuming memory is not necessarily a problem. It is about how much and if it never gets released. Can you run as both a service and regular app and reproduce the exact same memory profile? Positive. The past couple days Ive switched between a service and app trying to solve the issue. Both ways consume 99% of my ram while recording TV and the recordings end up corrupted. After the recordings"finish" the memory doesnt release. Last night I turned off the transcoding of recordings on the fly and the problem stopped. So far today Ive ran the service and the app this way and no issues. Edited September 6, 2017 by TylerV76 Link to comment Share on other sites More sharing options...
TylerV76 84 Posted September 6, 2017 Share Posted September 6, 2017 (edited) Heres 3 logs from the recordings that crashed last night. Not sure if this will help or not. There isnt a server log for this time for some reason, just the recording log. record-transcode-8d417114-4fe3-427b-8881-cf2d2fa35a04.txt record-transcode-197aeb1d-3344-4863-ba44-fa1b858751e2.txt record-transcode-79082953-7a43-4eb1-8f04-616bf4243dd8.txt Edited September 6, 2017 by TylerV76 Link to comment Share on other sites More sharing options...
TylerV76 84 Posted September 6, 2017 Share Posted September 6, 2017 (edited) The first attachment is a screenshot I just took while recording 2 shows and turning on "Automatically convert recordings to a streaming friendly format". I stopped the recordings and restarted the server. I then turned off the setting to "Automatically convert recordings to a streaming friendly format". The 2nd screenshot shows the results when Ive done that. Both sets of recording are the same shows. Allowing it to transcode while recording instantly locks up the system.The reason I had this still on was the ability to fast forward an active recording. On stable version .30 that wasnt possible. It looks like the .8 beta though is allowing me to do so. Also, as you see in the screenshot, emby is running as an app in these scenarios. Edited September 6, 2017 by TylerV76 Link to comment Share on other sites More sharing options...
dcook 266 Posted September 6, 2017 Share Posted September 6, 2017 Seems like most of the people reporting this issue are using the PVR function. If you don't make recordings are you seeing the same memory usage? 1 Link to comment Share on other sites More sharing options...
srjacobs 1 Posted September 7, 2017 Share Posted September 7, 2017 FYI - I had issue with Emby continuing to use more and more memory without any recording or viewing going on - would climb above 3gb if I let it - ended up working around it by using the restart plugin to restart the server every day - that way it would not grow too large to crash my system or cause memory errors like it did initially. I am running version 3.2.30 - but I saw this problem on the previous level as well - I forget now the exact version number. Anyhow - I am running this on Windows 10 - creator update level. I am not running Emby as a service. Based on some of the discussion on this thread - I decided to turn off all of the settings on the DLNA page and restart the server to see if that made a difference. And so far the difference is pretty major. I restarted it around noon today - and at 1:47pm this afternoon I checked and Emby was using only 187.7mb. Right before I started typing this message - I checked again (8:13pm) and it was 168mb. So this may point to one or more of those functions being responsible - at least in my case - for the memory gowth over time. Note - in all cases where I saw memory usage continue to climb over several days - there was no usage of the server at all - it would have been just running scheduled tasks, etc. And the usage would start climbing immediately after startup - this was not something that didn't happen for example until overnight when most of the scheduled processes would typically be running. I am going to let it continue to run like this over the next several days - taking out the scheduled reboot - and see if the memory usage remains stable. If it does - I may try turning back on - one by one - the DLNA options to see if I can pinpoint which one or ones seem to be triggering the memory usage to climb like it has for me previously. Link to comment Share on other sites More sharing options...
TylerV76 84 Posted September 7, 2017 Share Posted September 7, 2017 Seems like most of the people reporting this issue are using the PVR function. If you don't make recordings are you seeing the same memory usage? Nope. It starts happening to me during recordings only and only if I let it transcode while recording. So far today I haven't had any issues after turning that off. Sent from my SM-G950U1 using Tapatalk Link to comment Share on other sites More sharing options...
Tonos 6 Posted September 7, 2017 Share Posted September 7, 2017 (edited) I'm seeing this too, ive posted a memory usage probe below. You can see it hummed along nicely till Aug 21st. I'm unsure what exactly, may have been a plugin update. I didnt pick up on the memory gains and it sent the VM unresponsive around the 25th. Since then ive had to regularly restart it. Prior to that the only real restarts were during plugin or application updates. It does run as a service and uses the NextPVR plugin, and I'm always transcoding recorded TV shows. Library size is over 7TB, so i guess you would call that a large library, and my logs dont go that far back unfortunately. Having said all that, it still runs great. Edited September 7, 2017 by Tonos Link to comment Share on other sites More sharing options...
Happy2Play 8361 Posted September 7, 2017 Share Posted September 7, 2017 Obviously this has to be tied to recordings and/or converting media as there only appears to be a select set of users experiencing this. With 38TB of data I don't see Emby really ever use more than 1GB of memory. So it still comes down to what variables apply to this issue. Link to comment Share on other sites More sharing options...
denz 426 Posted September 7, 2017 Share Posted September 7, 2017 This is exactly why I posted in the testing can there be a limit on the amount of memory emby uses because when it is transcoding it uses all of it and other applications start crashing. Link to comment Share on other sites More sharing options...
jnheinz 17 Posted September 7, 2017 Share Posted September 7, 2017 I have been following this topic from the beginning. There have been a variety of different attempts to reproduce the problem using Live TV, transcoding, scheduled tasks & what not. No strong effort has been made to distinctly identify which Emby Server version the regression occurred at, as this can be pretty cumbersome. Here is my brief analysis on what people seem to believe is causing this & my thoughts on each item -> #1 - Plugins. This has been largely removed as a theory due to some people using NO plugins. There is no common plug-in being presented amongst users experiencing the problem. #2 - Live TV / PVR / Media Conversion. This seems to be a definitive trigger, but it is not a requirement for the memory leak to occur. There are users who have no tuner who are encountering the memory leak. #3 - Running as a service. This has been largely removed as a theory through simple tests of running it through the tray icon. #4 - Windows vs Linux. I have yet to see a bug report from a Linux installation, so it appears to be isolated to Windows primarily at this point at least. This topic is posted in Windows, so it may not be getting enough visibility to Linux users. #5 - Library Size. Not enough data to draw any conclusion. #6 - Client Type. There is no common denominator for a specific client type or version that may be aggravating the memory leak. Some users are Kodi-only. Some users have a mixture of Roku & Web. Some users have a mixture of more than 3 client types. #7 - Windows Updates. Not enough data to draw any conclusion, but the problem did seem to initially surface in June. #8 - Age of Installation. Primarily older installations, but there is not enough data to draw any conclusion. It would be interesting to rebuild the server from OS on up, install Emby Server & restore the configuration to see if can be reproduced. May have missed some stuff, but these are my thoughts. Link to comment Share on other sites More sharing options...
TylerV76 84 Posted September 7, 2017 Share Posted September 7, 2017 I have been following this topic from the beginning. There have been a variety of different attempts to reproduce the problem using Live TV, transcoding, scheduled tasks & what not. No strong effort has been made to distinctly identify which Emby Server version the regression occurred at, as this can be pretty cumbersome. Here is my brief analysis on what people seem to believe is causing this & my thoughts on each item -> #1 - Plugins. This has been largely removed as a theory due to some people using NO plugins. There is no common plug-in being presented amongst users experiencing the problem. #2 - Live TV / PVR / Media Conversion. This seems to be a definitive trigger, but it is not a requirement for the memory leak to occur. There are users who have no tuner who are encountering the memory leak. #3 - Running as a service. This has been largely removed as a theory through simple tests of running it through the tray icon. #4 - Windows vs Linux. I have yet to see a bug report from a Linux installation, so it appears to be isolated to Windows primarily at this point at least. This topic is posted in Windows, so it may not be getting enough visibility to Linux users. #5 - Library Size. Not enough data to draw any conclusion. #6 - Client Type. There is no common denominator for a specific client type or version that may be aggravating the memory leak. Some users are Kodi-only. Some users have a mixture of Roku & Web. Some users have a mixture of more than 3 client types. #7 - Windows Updates. Not enough data to draw any conclusion, but the problem did seem to initially surface in June. #8 - Age of Installation. Primarily older installations, but there is not enough data to draw any conclusion. It would be interesting to rebuild the server from OS on up, install Emby Server & restore the configuration to see if can be reproduced. May have missed some stuff, but these are my thoughts. In my instances heres what Ive come across. #5 - Library Size. Not enough data to draw any conclusion. - Doesnt seem to matter for me. I have 1 server with 9TB of data and one with 4.69GB of data. The issue happens on both. It also happens on a test server that has no data. #6 - Client Type. There is no common denominator for a specific client type or version that may be aggravating the memory leak. Some users are Kodi-only. Some users have a mixture of Roku & Web. Some users have a mixture of more than 3 client types. - I use FireTV, Xbox One and Emby Theater on Windows 10. The issue happens when using any of the 3. #8 - Age of Installation. Primarily older installations, but there is not enough data to draw any conclusion. It would be interesting to rebuild the server from OS on up, install Emby Server & restore the configuration to see if can be reproduced. - I installed emby on a PC I use strictly for testing that I reloaded a clean install of Windows 10 and a clean install of emby and the problem persisted if I allowed emby to transcode recordings while they were active. Last night I was able to get through a night of recording that consisted of 7 episodes (3 on one server and 4 on the other) without any issues at all. I was also able to view 2 of the recordings while they were in progress and fast forward while they were still in progress, without any issues what so ever. My memory usage never crossed 300MB during this time on either server and no recording failed or got corrupted. This was while running both servers as an app and not a service. Both servers are running the .8 beta. All in all everything worked exactly as it should and today my memory on both machines is under 200MB, 1 is down to 109MB. I have no Plug-Ins at all and I have the creator update on both machines so they are fully updated. Tonight will be another heavy night of recording so hopefully I have the same results. Link to comment Share on other sites More sharing options...
tekman13 0 Posted September 7, 2017 Share Posted September 7, 2017 In my instances heres what Ive come across. #5 - Library Size. Not enough data to draw any conclusion. - Doesnt seem to matter for me. I have 1 server with 9TB of data and one with 4.69GB of data. The issue happens on both. It also happens on a test server that has no data. #6 - Client Type. There is no common denominator for a specific client type or version that may be aggravating the memory leak. Some users are Kodi-only. Some users have a mixture of Roku & Web. Some users have a mixture of more than 3 client types. - I use FireTV, Xbox One and Emby Theater on Windows 10. The issue happens when using any of the 3. #8 - Age of Installation. Primarily older installations, but there is not enough data to draw any conclusion. It would be interesting to rebuild the server from OS on up, install Emby Server & restore the configuration to see if can be reproduced. - I installed emby on a PC I use strictly for testing that I reloaded a clean install of Windows 10 and a clean install of emby and the problem persisted if I allowed emby to transcode recordings while they were active. Last night I was able to get through a night of recording that consisted of 7 episodes (3 on one server and 4 on the other) without any issues at all. I was also able to view 2 of the recordings while they were in progress and fast forward while they were still in progress, without any issues what so ever. My memory usage never crossed 300MB during this time on either server and no recording failed or got corrupted. This was while running both servers as an app and not a service. Both servers are running the .8 beta. All in all everything worked exactly as it should and today my memory on both machines is under 200MB, 1 is down to 109MB. I have no Plug-Ins at all and I have the creator update on both machines so they are fully updated. Tonight will be another heavy night of recording so hopefully I have the same results. This is all with transcoding disabled? My installation was clean, latest emby release (not beta), win 10 creators update. Sent from my SAMSUNG-SM-N920A using Tapatalk Link to comment Share on other sites More sharing options...
TylerV76 84 Posted September 7, 2017 Share Posted September 7, 2017 This is all with transcoding disabled? My installation was clean, latest emby release (not beta), win 10 creators update. Sent from my SAMSUNG-SM-N920A using Tapatalk Yes. The only thing I disabled was "Automatically convert recordings to a streaming friendly format" as seen in the below image. Link to comment Share on other sites More sharing options...
TheHwyman 5 Posted September 7, 2017 Share Posted September 7, 2017 (edited) Fyi, Interesting update... I took a peak at things last night (err..early this morning around 1:30am), on the server and the Emby service process was at that point up to just a hair over 6 GB memory consumed. Since my last post (Monday), where the Emby process was at ~4.5 GB utilized it had consumed another 1.5 GB of memory in just a hair over 2 days. Checked the Emby logs, there was zero user activity over that whole two day period... as in nothing was streamed, so only normal scheduled tasks taking place and whatever synchronizing that takes place while (2) of the Kodi client machines sit there idly connected (they are always on/connected 7/24) but not doing anything. As I had mentioned previously, I perform all my LiveTV/PVR stuff separately outside of Emby using the NextPVR s/w service on my server directly talking to my Kodi clients through Kodi's LiveTV/PVR embedded support. However, I had figured that I would make the change to fully Emby (decommission NextPVR) at some point, but had not done it as of yet. In the meantime, my (2) HD Homerun boxes were ID'd in Emby's LiveTV configuration eventhough not being utilized in any way. I had configured Emby to connect to ScheduleDirect and pull down 7 days of guide data every 24 hrs and that was really the only thing going on with LiveTV to my knowledge. So at 1:30am when I saw Emby up to 6 GB of memory usage and no client activity whatsoever in over 2 days... I thought I'd try something, I went in to the Emby LiveTV config and removed/deleted the HD Homerun tuners so they don't even show up / appear. Then I deleted the ScheduleDirect configuration, so in effect there is absolutely nothing on the LiveTV config page... just a blank page. Restarted the Emby service and watched it for 5 minutes to see it climb up to and level off at ~350 MB memory usage. I connected through the dashboard interface to confirm all was ok... then went to bed. Btw, all the scheduled tasks that Emby performs are scheduled to happen between midnight and 5am daily. I just had a few minutes, so I took a look at my server and now at 1:00pm almost 12 hrs later... Emby service is sitting at ~260 MB memory use and holding steady... hmmm, typically within the first 12 hrs (from previous observations) from restarting the Emby service... it would creep up to about 600 - 700 MB usage, here it hadn't and actually decreased by 100 MB. Granted it has only been 12 hrs, but that's interesting none the less and I will check in on it later tonight to see how it looks... Edited September 7, 2017 by TheHwyman 1 Link to comment Share on other sites More sharing options...
Jdiesel 1114 Posted September 7, 2017 Share Posted September 7, 2017 (edited) Fyi, Interesting update... I took a peak at things last night (err..early this morning around 1:30am), on the server and the Emby service process was at that point up to just a hair over 6 GB memory consumed. Since my last post (Monday), where the Emby process was at ~4.5 GB utilized it had consumed another 1.5 GB of memory in just a hair over 2 days. Checked the Emby logs, there was zero user activity over that whole two day period... as in nothing was streamed, so only normal scheduled tasks taking place and whatever synchronizing that takes place while (2) of the Kodi client machines sit there idly connected (they are always on/connected 7/24) but not doing anything. As I had mentioned previously, I perform all my LiveTV/PVR stuff separately outside of Emby using the NextPVR s/w service on my server directly talking to my Kodi clients through Kodi's LiveTV/PVR embedded support. However, I had figured that I would make the change to fully Emby (decommission NextPVR) at some point, but had not done it as of yet. In the meantime, my (2) HD Homerun boxes were ID'd in Emby's LiveTV configuration eventhough not being utilized in any way. I had configured Emby to connect to ScheduleDirect and pull down 7 days of guide data every 24 hrs and that was really the only thing going on with LiveTV to my knowledge. So at 1:30am when I saw Emby up to 6 GB of memory usage and no client activity whatsoever in over 2 days... I thought I'd try something, I went in to the Emby LiveTV config and removed/deleted the HD Homerun tuners so they don't even show up / appear. Then I deleted the ScheduleDirect configuration, so in effect there is absolutely nothing on the LiveTV config page... just a blank page. Restarted the Emby service and watched it for 5 minutes to see it climb up to and level off at ~350 MB memory usage. I connected through the dashboard interface to confirm all was ok... then went to bed. Btw, all the scheduled tasks that Emby performs are scheduled to happen between midnight and 5am daily. I just had a few minutes, so I took a look at my server and now at 1:00pm almost 12 hrs later... Emby service is sitting at ~260 MB memory use and holding steady... hmmm, typically within the first 12 hrs (from previous observations) from restarting the Emby service... it would creep up to about 600 - 700 MB usage, here it hadn't and actually decreased by 100 MB. Granted it has only been 12 hrs, but that's interesting none the less and I will check in on it later tonight to see how it looks... Interesting, is it possible that Emby is holding onto old guide data? I wonder if there is any correlation between the number of channels and number of days of guide data being pulled and the increase in memory usage per same period. Have we confirmed that the memory usage only occurs on servers using LiveTV? Edited September 7, 2017 by Jdiesel 1 Link to comment Share on other sites More sharing options...
jnheinz 17 Posted September 7, 2017 Share Posted September 7, 2017 Interesting, is it possible that Emby is holding onto old guide data? I wonder if there is any correlation between the number of channels and number of days of guide data being pulled and the increase in memory usage per same period. Have we confirmed that the memory usage only occurs on servers using LiveTV? While some people have Live TV, not all do. I had a tuner, but I have never used it.. nor did I have guide data. When I deleted it, the leak persisted after a reboot. For example (a test I have been doing), I have an Emby Server 3.2.29.0 installation in Windows with NO libraries and NO Live TV that has been creeping up from 350MB to 1.3GB over the course of a week. Granted this is a little slower than installations WITH libraries.. There is absolutely zero media. I am going to let it go to see if it can crash the server. The scheduled tasks are still there along with a few plug-ins. If a server with no libraries & no tuners can leak memory like that, there is clearly an issue with some underlying core component as @@Luke suggested like sqlite or the web server. I can probably delete all plug-ins & remove the schedules from all tasks & I think it will still leak. Link to comment Share on other sites More sharing options...
Happy2Play 8361 Posted September 7, 2017 Share Posted September 7, 2017 While some people have Live TV, not all do. I had a tuner, but I have never used it.. nor did I have guide data. When I deleted it, the leak persisted after a reboot. For example (a test I have been doing), I have an Emby Server 3.2.29.0 installation in Windows with NO libraries and NO Live TV that has been creeping up from 350MB to 1.3GB over the course of a week. Granted this is a little slower than installations WITH libraries.. There is absolutely zero media. I am going to let it go to see if it can crash the server. The scheduled tasks are still there along with a few plug-ins. If a server with no libraries & no tuners can leak memory like that, there is clearly an issue with some underlying core component as @@Luke suggested like sqlite or the web server. I can probably delete all plug-ins & remove the schedules from all tasks & I think it will still leak. So it still comes back to why you have a issue and I don't. What plugins? So I can perform the same test on a Windows 10 system. But I have a feeling I will not be able to reproduce. Link to comment Share on other sites More sharing options...
jnheinz 17 Posted September 7, 2017 Share Posted September 7, 2017 Rotten Tomatoes isn't offered anymore, so I have removed it as a result. I am wondering if I should just wipe all settings to a completely out of the box experience. 2017-09-06 23:59:59.951 Info App: Plugins: Emby.Kodi Sync Queue 1.4.6362.2868 Server Configuration Backup 1.0.1.20 PushBullet Notifications 3.0.6143.20390 Rotten Tomatoes Reviews 3.0.6134.23469 Podcasts 1.0.6287.42903 Link to comment Share on other sites More sharing options...
Happy2Play 8361 Posted September 7, 2017 Share Posted September 7, 2017 Well iit would make since some of those plugins will alway be using resources. But I will add them and test. Link to comment Share on other sites More sharing options...
jnheinz 17 Posted September 7, 2017 Share Posted September 7, 2017 Well iit would make since some of those plugins will alway be using resources. But I will add them and test. My next test will be with no plug-ins once (if*) this leaks to the point of consuming all server memory (4GB). Link to comment Share on other sites More sharing options...
Happy2Play 8361 Posted September 7, 2017 Share Posted September 7, 2017 My next test will be with no plug-ins once (if*) this leaks to the point of consuming all server memory (4GB). Are the plugins configured? As my test will probably show nothing since I have never used or need these plugins (so they are unconfigured). 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