Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Niek]

I've noticed that after running Media Center for a couple of hours it started to occupy about 1.3Gb of memory until it stopped responding altogether.

Have other people seen this as well and is there anything I can do in order to troubleshoot?
(Running Mini Mac with OSX 10.7.5.)

Thanks,

Niek.

[Matt]

That's not good.

Does it only happen if you do some particular action (use DLNA, play audio, etc.)?

It would be helpful if you could try narrowing down what action might be causing the leak.

Thanks.

[Niek]

Well, I haven't been doing a lot to be honest.

I've imported a (15000 track FLAC) library located on my NAS, toyed around with the user interface (sort by artist, sort by album, etc) and played a few songs over the standard speakers.

Still waiting for my FireWire cable to arrive so haven't hooked it up to a DAC yet.

Hope this helps, please let me know if you want me to test something specific.

Cheers,

Niek.

[Matt]

Hope this helps, please let me know if you want me to test something specific.

It would be helpful if you could find an action that causes memory to spike.

Importing, sorting, thumbnailing, etc.

I haven't been able to reproduce this here.

Thanks.

[johnjen]

I too have noticed that the amount of memory 'creeps' up after continuous use.

I usually fuss with trying out different functions which can result in crashes.
But when I look at my memory in use monitor, I have noticed it 1-2GB larger than when I first began playing with MC's knobs and buttons.

And this seems to be the case for both 10.7.5 and 10.6.8

JJ

[JimH]

If you just start MC and don't do anything, does memory usage grow?

[freddiejohn]

Please see post re: playback stuttering.

Memory usage when MC is open but not playing:  started 9:16  43.9 MB     at 10:16  179.2
Fred

[Niek]

If you just start MC and don't do anything, does memory usage grow?

Yes that seems to be the case. Started with 120, now at 140.8Mb and steadily growing without touching anything.

I'll leave the application running over night and will let you know tomorrow.

[MrC]

You folks know about dtruss?

[Dan1970]

After nearly a day of just running Media Center, not playing anything, memory usage went from 120Mb to over 700 at the moment and continuously increasing.

[Matt]

After nearly a day of just running Media Center, not playing anything, memory usage went from 120Mb to over 700 at the moment and continuously increasing.

That helps.

What types of files are in your library?  And how many?

If you run Auto-Import manually, does memory usage grow?

What if you disable 'Media Network'?

Sorry for all the questions, but so far using the Leak finding Profiler tools in XCode, we're not seeing these leaks.  So there must be some particular action thing that's causing trouble, and we just need to figure it out.

[Matt]

I might add that memory usage at 200MB or less is probably normal.

But if it grows continually up past 500MB, there is a problem.

On Windows, minimizing the program unloads lots of stuff (thumbnails, pieces of the database, etc.) but this functionality isn't in the Mac version yet.  It might be interesting to hook this up and see how much memory is reclaimed.

[Dan1970]

I have 18067 flac files in my library on a network disk.

I'll try turning off auto-import and media network and get back to you.

I don't mind the questions, glad I can help, that's why I posted in the first place!

[MrC]

On Windows, minimizing the program unloads lots of stuff (thumbnails, pieces of the database, etc.) but this functionality isn't in the Mac version yet.  It might be interesting to hook this up and see how much memory is reclaimed.

You're going to find that the *nix VM systems are fantastic, and you have less need to micro-manage resource loading and unloading.

[Weedos123]

If its any use.

Mac Mini 2012, 10.8.3, 8GB RAM.  2322 files 90% aiffs remainder dsfs. Auto import is off.  DLNA is on.

After using it yesterday, I just left it minimised and sent the mini to sleep. Woke mini up and un minimised MC. Activity monitor sat at around 718MB used and 22% processor, left it alone for a minute or 2 to see what happened to memory usage and it didn't move. So minimised it, maximised it, checked to see if auto import was on and went back to activity monitor. In the time it has taken me to type this, memory usage is now 944.9MB and rising steadily and CPU% is up to 36.7% and rising steadily in sync with memory usage.  In the time it took me to check this its now 1.14GB & 61.2%CPU.

So I expect it to crash soon.

Paul

[Weedos123]

So its now 2 mins later than the last post and CPU usage has dropped to around 24% and is stable at that figure.  Memory usage has dropped to 1.11GB and is static.

So something finished doing something.

Paul

[kwyatt99]

Just started paying attention to the Activity Monitor after reading this thread. I'm 10.6.8, Build 154. When I start MC, CPU usage is about 5%, Real Mem maybe 100MB. And it seems to play without dropouts. After 30-40 minutes, the CPU is over 70%, sometimes spiking to 95% (or even over 100%!), the Real Mem is over 800MB and climbing. Once the Real Mem reached about 600MB, I noticed a lot of dropouts in the playback. At this rate I'm guessing this thing is going to crash and burn at some point. The only other program I had running in the background was a static Firefox. And nothing in MC changed when I quit Firefox.

(In a little more than the time it took me to type this, CPU bouncing around 80% usage, Real Mem= over 1000 MB!)

[Matt]

It would be helpful to see a log from a run where the memory grows out of control.

You could email the log (Help > Logging) to logs at jriver dot com.

Thanks.

[Dan1970]

I also saw cpu usage over 100% during the times memory usage was high (1gb and higher).

I'll try to send a log when I reach high memory usage again.

[Weedos123]

Restarted MC and tried to provoke it and in my case it looks like it's the dsf files being played using DoP thats causing it. They were being played yesterday as well.

Log files sent.

Paul

[kwyatt99]

I'll figure out how to send a log of a run.

BTW, I closed MC down, re-started it and left it for a couple hours, without playing anything, and the CPU stayed at 4-5%, the Real Mem stayed at 56.2MB---neither increased at all. Hope that helps.

[Fred1]

MC is constantly eating up memory here, too.
About 0.1-0.2 MB per minute on a MacMini with OS 10.6.8.

CPU is about 3% without playing anything.

[Matt]

Thanks.  The log helped.

There are a couple problems I've reproduced.

Waiting in the core threading engine was using busy loops instead of proper mutex waits.  This explains the high CPU usage, and will be fixed next build.

Next, there's a problem with memory playback where the I/O is working a little harder than it needs to.  I'm still trying to figure it out, but it should get fixed next build as well.

Thanks again.

[Dan1970]

One thing I have noticed is that when I just have my mouse pointer over an artist (in artist view) with multiple albums so the thumbnails of the cover art of all albums is shown one after another, the memory usage increases much faster. When I move my mouse to something else for example the tree, memory usage still increases but at a slower pace.

[Matt]

Testing of build 18.0.155 (available now) with regards to this issue would be appreciated.

Thanks.

[Weedos123]

Installed Build 155 and currently playing a 96kHz/24bit aiff and memory usage continues upward. Started at around 80MB and now after 40 minutes or so its about to break the 1GB barrier.  Cpu usage was constantly in the 40's or 50's%, although it has now dropped to be in the twenties.  Stopped and restarted playback made no difference its still going up.

I'll email the log for this.

Paul

[MrC]

I saw that you were doing lots of stat64's on various language files that probably will never change during the run of MC.  And gazillions of semaphore waits when moving the mouse even a fraction.

[johnjen]

I started Activity Monitor then MC.
I didn't run anything in MC, I just started it and left it up on the desktop.

It started at 71.3MB
10 minutes later it was using 74.4MB
30 minutes after that it was using 82.8MB

Again all I did was open the app, nothing more.

Now I'll close it, then re-open it and run some music thru it.

JJ
edit this is on x.x.155

EDIT  I restarted the app, ("real memory") = 71.2MB

I select an album and start playing music.  "Real memory" jumps to 281.3MB and continues to climb

After 14 minutes and 2 songs = 130MB (FLAC files), "real memory" = 511.9MB ∆=230MB

I'll play the remainder of this album and add those details when done.


JJ

[johnjen]

All Righty then…

So I listened to the rest of the album (908MB total) and soon the pauses started.

Then I noticed that the %cpu spiked during the pauses.
All the while the real memory rose.  But not always.

It rose up to 885MB then dropped down to 665MB then began to climb back up and went to 890MB the dropped again but only to 870MB.  Then continued its climb to 1.13 GB by the end of the album.

"Private Memory" also rose in a similar fashion (rose then fell back then rose again) and peaked at 1.021 GB at the end of the album.

So the peak %cpu times varied and not all peaks caused a playback pause.  But every playback pause was accompanied by a %cpu peak.

The pauses coincided with a range of %cpu readings from lows of 20.9% and 32.9% to highs of 179.6% and 168.3% with LOTS in between, both less than and greater than 100%.  But near the end I saw the %cpu drop to 0% then shoot up to 179.8% and an all time high of 204.8%  But these events did NOT create a pause in playback.

Another interesting behavior was during 'normal' %cpu readings, the %cpu readings would bounce around from 11% to 14% then jump, then settle back into this range.

But after the real memory reached close to 1GB the 'normal' %cpu readings moved up to 16% to 19% with ≈25% readings showing up frequently as the baseline 'normal'.

And lastly, I paused the player between songs (the real memory was well past 1GB) and after the %cpu settled down it jumped from under 10% to 132.9% for a brief time, then settled down again.

I hope this helps.

JJ
edit: I just started to play another album after leaving the app alone for over an hour.

It now is using 1.17GB and climbing… IOW it just kept going and didn't 'purge' the memory it used during the previous album.

[kwyatt99]

Downloaded Build 155. I'm OS 10.6.8. Still huge memory usage resulting in playback dropouts after it reaches about 300 MB. Almost constant dropouts and/or stuttering. The only difference I saw was the memory usage went up and down instead of constantly upwards. I've included a log. Hope it helps.

[kwyatt99]

Just noticed something else which I don't think has been reported. I opened MC and started playing albums, watching the Real Mem rise. But whenever I minimized the program (music STILL playing), it seems the Memory rise just stops dead, and the music keeps playing fine. The Mem readings don't go down, they just stop going up when the program is minimized. Hope this helps.

[kwyatt99]

In addition to what I described yesterday about playing while the program was minimized: Playing MC in "Mini View" ALSO seems to stop the Real Mem rise (although sometimes between tracks occasionally it might jump a few MB, but then settle down and stay pretty constant throughout. And I haven't had the stuttering/dropouts when I can keep the Real Mem from rising in this manner. To this novice, it looks like the memory "leak" has less to do with the actual audio playback and more to do with the visual and control structure of the program.

[Matt]

Testing of build 156 with regards to this issue would be appreciated.

I think it may be fixed, but would appreciate confirmation.

Thanks.

[kwyatt99]

I loaded 156 into my IMac (Mountain Lion) and MacBook Pro (10.6. and neither one show the runaway Real Mem rise as before. They seem to settle in at about 150-170 MB. The sound quality also seems to have improved markedly (more depth and detail).

Good job! Thanks.

[johnjen]

Loaded x.x.156
Thus far the real memory seems to track with the actual file being played.  IOW it goes up with larger files and goes down with smaller ones.  And once the file is loaded into memory the amount of memory being used stays constant.

Private memory jumps up and back down with each new track being played but only by ±10-100MB or so.  And it too stays constant after the new track is loaded.

And the %cpu has dropped precipitously to 1.6 to 2.0%

And when the stop button is pressed and the track list is cleared and the real memory drops back to initial levels as does the private memory.


JJ

[Niek]

Testing of build 156 with regards to this issue would be appreciated.

I think it may be fixed, but would appreciate confirmation.

Thanks.

This looks a LOT better Matt!

First tests show similar positive results as with the other users; will do extensive testing over the coming Easter weekend.

Thanks!

Niek.

[Weedos123]

Lots better here also. Memory usage rises and falls in relation to what the programme is doing. Media network has stopped firing of requests every 0.1 secs as it was before. The programe is also now responsive the next day after being left hidden overnight doing nothing. CPU usage down to under 10% all the time.

Paul

[Niek]

This looks a LOT better Matt!

First tests show similar positive results as with the other users; will do extensive testing over the coming Easter weekend.

Thanks!

Niek.

This issue has definitely been fixed; the application is very economical with memory now through multiple days of testing.

Well Done!!