Serious memory leaks in Recording Service with 1.1.5

[BotLogic]

OS: Win XP x64 with SP2
App ver: 1.1.5 (although this issue has been present for quite a while)
Extra plugins: None
Card type: ATI Theater 550 Pro
RAM: 4 GB

When the GB-PVR Recording Service starts recording a show in the background, my system RAM decreases and goes down to less than 100 MB free, making my system quite unusable. It stays this way until the point the recording is complete, after which I suddenly and instantaneously recover all the lost RAM, and end up with about 3 GB available. Something thus gobbles up 2.9 GB of RAM! This apparently is indicative of serious memory leaks in the GB-PVR Recording Service application. What can be done about this? Thanks.

At this time I do not have a perf graph, but I suppose I can get one.

[sub]

Its actually fairly normal that the recording services uses about 100MB, if not more if it has done an EPG update. The way .net memory management works means that memory that is no longer used by the application is not freed back to the operating system until Windows tells the .net framework it really needs the application.

I'm not aware of any leaks, but if you're sure it is, then try graphing the 'working set' and 'virtual bytes' (of GBVPRRecordingService.exe) in Perfmon.exe over long period of time and I'll take a look.

GB-PVR's recording service using 100MB on you system 4GB shouldnt make your system "unusable".

[BotLogic]

GB-PVR's recording service using 100MB on you system 4GB shouldnt make your system "unusable".

No, no, <100 MB is all that's left free on my system for the duration a recording is happening.

[InVermont]

I read it as the recording service takes 3.9GB of memory, leaving 100MB free for the rest of the system...
I run with 512MB of RAM on my PVR system, and never see it drop like that. If GB-PVR leaked memory at such a rate, I would find it unusable.

[BotLogic]

I read it as the recording service takes 3.9GB of memory, leaving 100MB free for the rest of the system...

There is a small error in this interpretation still. I claim that the recording service takes up about 2.9 GB (not 3.9), the rest of the system takes up about 1 GB, and about 100 MB is left free.

[sub]

Ah sorry, skim reading and misinterpretted.

As I suggested above, run perfmon (which comes with windows), and graph the 'working set' and 'virtual bytes' of GBVPRRecordingService.exe. Start graphing before the recording starts and leave it for a run until the recording service is running this large amount of memory, then post a screenshot of the graph for me to look at.

I've seen no other reports of this, so its probably something specific to the drivers on your machine or something similiar.

[Sam]

I experienced a similar issue as this, but with page file, which I believe is related to the RAM. For me this happened while browsing and selecting skin components. The system was grounding to a halt with every move down the list. I was using Community 3 and an MCE variant. Don't know if I chose a high res theme or something. I got a quad core with 2GB of RAM but a measley ATI x1250 integrated VGA that's meant to handle Blue-Ray. Looked in WinXP task manager and my Page File (PF) had shot up to 3.5 Gb Manager and eventually I was bailed out of the skin selector. I switched over from Cyberlink Mux to MS- and things eased off. This may have been because my motherboard said to change settings in power DVD to not use hardware acceleration. I'm confused through because the thing that improved things was the mux filter switch? I'd appreciate any light on this, if it's related.

[BotLogic]

As I suggested above, run perfmon (which comes with windows), and graph the 'working set' and 'virtual bytes' of GBVPRRecordingService.exe. Start graphing before the recording starts and leave it for a run until the recording service is running this large amount of memory, then post a screenshot of the graph for me to look at.

I logged data for a one hour recording, and also for 15 mins before and after the recording. I recorded the Virtual Bytes and Working Set for GBPVRRecordingService as you wanted, which don't look out of bounds to me. I also recorded the Processor Time for it, which seems okay too; and the overall Available MBytes for the system which drops gradually - this is the problem.



As seen in the picture, note that the scales for Virtual Bytes and Working Set are their default values, but the scales for Available MBytes and % Processor Time have been altered as shown to fit in the graph. I think the Available MBytes would've gone even lower had the recording continued for longer than an hour.

[sub]

Sorry, I dont know. I'm not able to reproduce it here.

[BotLogic]

Sorry, I dont know. I'm not able to reproduce it here.

I suppose it may be OS or card specific. Is there any workaround, such as a way I can limit the max memory used by the recording service or by Dot Net? Again, this particular option may not help even if it exists because a leak by definition probably makes a max limit irrelevant.