1.27.0 Memory leak in TVService (2 Viewers)

[doskabouter]

Just did a bit of research on memory profilers but that is not a trivial task to setup (at least not for the free visual studio one (Install the Stand-Alone Profiler - Visual Studio (Windows) and Profiler command line - Instrument .NET service, get memory data - Visual Studio (Windows)).
Other ones I found were paid but with a free trail of 2-3 weeks, so you need to be sure to be able to finish the full investigation within that timeframe...
I know it's not of great help, but I thought I'd share it anyway

 

[Berney]

Just did a bit of research on memory profilers but that is not a trivial task to setup (at least not for the free visual studio one (Install the Stand-Alone Profiler - Visual Studio (Windows) and Profiler command line - Instrument .NET service, get memory data - Visual Studio (Windows)).
Other ones I found were paid but with a free trail of 2-3 weeks, so you need to be sure to be able to finish the full investigation within that timeframe...
I know it's not of great help, but I thought I'd share it anyway

Thanks for that Doskabouter, it looks very useful. I'll give it a try out in a few weeks time, due to having higher priorities at the moment.
Hopefully that will lead to an answer to the problem.

 

[Brownard]

However, I did find a GC.Collect() function that can be used to trigger garbage collection. This suggests that TV Server could be modified to contain logic something like this:

As a general note on this, if GC.Collect were to resolve the issue then it's not a true memory leak as the GC only collects managed objects that the runtime can see are no longer being referenced, as oppose to either unmanaged memory being allocated outside of the runtime which the GC doesn't touch either way, or a lot of objects accumulating with a stray reference keeping them alive, which again the GC wouldn't touch because they are still referenced. The GC is highly optimised to handle memory management and will collect when memory pressure gets too high long before the process runs out of memory, so it is extremely unlikely to be a case of the GC not collecting soon enough, especially over the timespans we're looking at here, and is much more likely to be one of the other options (either unmanaged memory somewhere or an ever growing list of objects not being dereferenced). Bar some very exceptional edge cases where you know more than the GC about the lifetime of your objects and the process (which is usually never the case ) manually calling GC.Collect does more harm than good because it messes with it's heuristics.

 

[Berney]

A WORK AROUND !!!

Hello to everyone again.

I too was experiencing these problems.
I was using 1.25v of MP with 32 gigs of memory, win7.

The reason why it occurs is due to the the number of files scheduled to be recorded.

Solution:-
Check the number of scheduled recordings (and scheduled series to be recorded) and reduce them significantly.
Restart the tvservice and you will then notice the memory usage (as reported in task manager) drop significantly. Reduce the number of scheduled recordings enough and you should have no further troubles.
You might also find that 'record every time on every channel' uses up more memory when setting up a recording under 'Avanced Record' so I suggest using that feature sparingly.

The 'out of memory error' , seen in tvserver logs, always seems to occur when it has obtained a EPG update and it is presumably working on what it should keep and what it should discard regarding scheduled recordings.

It tends to crash when the memory of the tvservice reaches around 1.5 gigs of memory useage. I am guessing that in the code it has this figure set to limit real memory useage (as opposed to slower paged memory) and the only way to move this problem along so that it does not occur for people with heavy recording schedules is to have it recompiled to say 3 gigs or more.

I do hope this helps anyone experiencing 'out of memory' crashes in tvservice.