Print

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

[mwillems]

Would someone try one of the latest arm builds playing a local list of preferable small files (so it has to transition through tracks frequently) and once playing, disconnect the network cable from their RPi and see if the leak still happens?

I don't have a Pi with a display attached handy, but I'll try and set something up over the weekend if no one can test.

[bob]

I don't have a Pi with a display attached handy, but I'll try and set something up over the weekend if no one can test.

Thanks, I will have one running here, just looking for duplication of results...

[bob]

Would someone try one of the latest arm builds playing a local list of preferable small files (so it has to transition through tracks frequently) and once playing, disconnect the network cable from their RPi and see if the leak still happens?

The result with the 21.0.7 build is that there is no leakage with the network disconnected. I'm going to try the current build. If the results are the same then we know where the leak is for arm anyway.
The AMD64 is different as far as I can tell, it leaks way more.

[mwillems]

The result with the 21.0.7 build is that there is no leakage with the network disconnected. I'm going to try the current build. If the results are the same then we know where the leak is for arm anyway.
The AMD64 is different as far as I can tell, it leaks way more.

Ok I hooked a Pi to a screen, pulled the network connection and started it playing.  After three hours (and 50 or so track changes), memory usage has grown about 1M, which is well within the margin of error.  So it looks like the ARM leak is network stack related.  Hope this helps, and let me know if there are any other tests I can run.

[bob]

Ok I hooked a Pi to a screen, pulled the network connection and started it playing.  After three hours (and 50 or so track changes), memory usage has grown about 1M, which is well within the margin of error.  So it looks like the ARM leak is network stack related.  Hope this helps, and let me know if there are any other tests I can run.

My resident memory use actually went down after a couple of days.
 

[mwillems]

My resident memory use actually went down after a couple of days.
 

I've been intermittently monitoring my work Pi (which doesn't have a network hook up), and I haven't seen any increases in memory usage at all.  I haven't seen decreases though, maybe you can share your secret as I need all the free memory I can get 

[Mark_NL]

Don't know if this is usefull, reporting things you already know and specially considering the unusual setup  MC-arm is running on. (OrangePI – Debian Jessie on an ancient kernel)

However, over the weekend set up a Munin node on the OPI and saw, as some reported before,  MC-ARM 20.129 is leaking too.
On the enclosed graph the first 2 periods of several hours playing (from server > sent to) are MC-ARM 20.129, the third is MC-Arm 21.14.  Memory increase is obviously steeper with 21-14, but still quite considerable with MC20.

At the moment it is running MC21-17-3.  EDIT: seems to be the same as 20.0.129

unfortunately i can't attach a monitor so network is essential to oparate.
I wonder if switching off the Media Network and playing from a local disk would do be equivalent to running without anny network connected?

[bob]

Don't know if this is usefull, reporting things you already know and specially considering the unusual setup  MC-arm is running on. (OrangePI – Debian Jessie on an ancient kernel)

However, over the weekend set up a Munin node on the OPI and saw, as some reported before,  MC-ARM 20.129 is leaking too.
On the enclosed graph the first 2 periods of several hours playing (from server > sent to) are MC-ARM 20.129, the third is MC-Arm 21.14.  Memory increase is obviously steeper with 21-14, but still quite considerable with MC20.

At the moment it is running MC21-17-3.  EDIT: seems to be the same as 20.0.129

unfortunately i can't attach a monitor so network is essential to oparate.
I wonder if switching off the Media Network and playing from a local disk would do be equivalent to running without any network connected?

It doesn't help to switch off media network, you need to pull the ethernet cable. This points to an issue in the socket listener code I believe.

[Mark_NL]

It doesn't help to switch off media network, you need to pull the ethernet cable. This points to an issue in the socket listener code I believe.

I noticed,
it cuts it almost in half though, maybe I've got two different hiccups.

[Mark_NL]

Being in the memory monitoring anyway, fired up a sleeping Debian Jessie VM with MC21 Amd64.
(there is no audio device, output > NULL)

Suspecting something with cover-art to contribute to growing footprint of MC-Arm, I did the same experiment on de Amd64 :
 
Play tracks with relatively big cover art included in the file (no thumbs build) random from a local library:  
a)   standard-view location “audio” with “display” in left bottom open (player is current playback zone)
b)   (on start up) mini-view and start playing current playlist

a: severe memory growth ;  b: modest  memory growth

And I have seen modest memory growth on my “main” mediaserver (MC-32bit on 64 bit Arch Linux) if I accidently let the view in state “a”  with the render it serves as current playback zone.