More > JRiver Media Center 26 for Linux
JRiver on Raspberry Pi has a memory leak?
mwillems:
Bob, I'm testing v. 26.0.20 and still seeing significant memory growth with the auto sync setting enabled. It increases slowly on every track change (it seems to grow about 1GB every five tracks or so for me), but I can force memory growth instantly by changing between library views rapidly (i.e. clicking back and forth between artist and genre, etc.).
My server is running Debian Stable (Buster), and I tested with clients running Debian Stable and Arch Linux.
bob:
--- Quote from: mwillems on January 24, 2020, 09:08:27 am ---Bob, I'm testing v. 26.0.20 and still seeing significant memory growth with the auto sync setting enabled. It increases slowly on every track change (it seems to grow about 1GB every five tracks or so for me), but I can force memory growth instantly by changing between library views rapidly (i.e. clicking back and forth between artist and genre, etc.).
My server is running Debian Stable (Buster), and I tested with clients running Debian Stable and Arch Linux.
--- End quote ---
Thanks, Hendrik also thinks it's still an issue... We'll look some more.
Hendrik:
I've been trying to reproduce this and check for memory leaks, but I could not find anything substantial, or even any evidence of misbehavior.
I did find a few tiny memory leaks, which I fixed, but all in the range of kilobytes, not mega or even gigabytes.
Syncing with the server does produce an increase in memory requirement - but only a one-time use.
When you sync the library back to the server, MC has to determine a "delta" of what actually changed. We don't store a change date for every single field (that would be insane), so instead we compare our local library to the remote library. To do this, it has to load the entire library completely into memory. This is usually not done outside of syncing, or until you have viewed every field of every file in your library manually. On a very large database, this can be quite some memory.
Once this data is loaded once, it should not grow further beyond that. A second sync process won't load it again, since its already loaded.
All that said, I also found one case where memory was being wasted that was only used conditionally, so I've cleaned that up and a fully loaded library, like in the sync process, should now use significantly less memory.
If this is still going on with the next version, and one of you can reproduce it reliably on a x86_64 system, we might ask you to collect some information for us.
mwillems:
--- Quote from: Hendrik on January 31, 2020, 05:28:07 am ---I've been trying to reproduce this and check for memory leaks, but I could not find anything substantial, or even any evidence of misbehavior.
I did find a few tiny memory leaks, which I fixed, but all in the range of kilobytes, not mega or even gigabytes.
Syncing with the server does produce an increase in memory requirement - but only a one-time use.
When you sync the library back to the server, MC has to determine a "delta" of what actually changed. We don't store a change date for every single field (that would be insane), so instead we compare our local library to the remote library. To do this, it has to load the entire library completely into memory. This is usually not done outside of syncing, or until you have viewed every field of every file in your library manually. On a very large database, this can be quite some memory.
Once this data is loaded once, it should not grow further beyond that. A second sync process won't load it again, since its already loaded.
All that said, I also found one case where memory was being wasted that was only used conditionally, so I've cleaned that up and a fully loaded library, like in the sync process, should now use significantly less memory.
If this is still going on with the next version, and one of you can reproduce it reliably on a x86_64 system, we might ask you to collect some information for us.
--- End quote ---
Thanks Hendrik! I've been experiencing this reliably on all linux platforms (amd64 and arm) for a few major versions, so I'll be happy to collect info if I can still reproduce it after the next build.
bob:
--- Quote from: mwillems on January 31, 2020, 09:05:35 am ---Thanks Hendrik! I've been experiencing this reliably on all linux platforms (amd64 and arm) for a few major versions, so I'll be happy to collect info if I can still reproduce it after the next build.
--- End quote ---
[Edited]
I can verify this happens in Linux and Mac at any rate back into MC25, Hendrik fixed some things but it's still happening for me. It seems to bump up on every track. I tried MP3 and M4A lossless.
On the Mac playing back files from my server it's gone from 100MB memory usage to 150MB in an hour or so and it may have stopped there...
On a Pi running Buster from 150MB to 180MB in about the same time, on an IdPi MC25 similar behavior.
On my AMD64 box after several hours it's up to 429MB but after a few hours that went back down to 320MB.
Not totally sure what's going on, letting the test run over the weekend...
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version