Print

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

[mwillems]

That seems rather unrealistic.  Memory allocation is a software thing.
What puzzles me the most is how this wants to be a Linux-exclusive problem. I've run all sorts of memory debuggers (leak finder, heap profiler, the works) and found no suspect results at all.

An actual leak would show up immediately. And even if it somehow stores memory references somewhere that are only free'ed on exit, those would've shown in the heap profiler.

Fair enough, just spitballing 

Perhaps it a system library mismatch issue?

I'll make another test build on buster and we'll see if the issue goes away for you.

If that could cause the issue, then that's a definite possibility as everything I'm running is on either Buster or Arch (which is newer yet).

[bob]

Fair enough, just spitballing 

If that could cause the issue, then that's a definite possibility as everything I'm running is on either Buster or Arch (which is newer yet).

You have a PM

[mwillems]

Ok I tested with the latest build and it did not resolve the memory leak.  I tested on both debian buster and on Arch clients, they behaved similarly.  Some things I noticed: the memory increase typically occurs alongside mediacenter pegging one CPU core for somewhere between five and ten seconds.  It also seems to coincide with SSDP broadcasts, but that's harder to say as those occure pretty frequently anyway.  For a test, I tried disabling all non-jriver SSDP devices on the network, but that didn't change anything. 

I'm stumped!

[bob]

Ok I tested with the latest build and it did not resolve the memory leak.  I tested on both debian buster and on Arch clients, they behaved similarly.  Some things I noticed: the memory increase typically occurs alongside mediacenter pegging one CPU core for somewhere between five and ten seconds.  It also seems to coincide with SSDP broadcasts, but that's harder to say as those occure pretty frequently anyway.  For a test, I tried disabling all non-jriver SSDP devices on the network, but that didn't change anything. 

I'm stumped!

Still though, it goes away if syncing is off, correct?

[mwillems]

Still though, it goes away if syncing is off, correct?

Yes, the memory stops increasing when the "auto-sync with server" client setting is off.  It doesn't release any memory that's already grown. 

But yeah, it's easy enough to live with that setting off, I just wanted to crack the case!

[bob]

Yes, the memory stops increasing when the "auto-sync with server" client setting is off.  It doesn't release any memory that's already grown. 

But yeah, it's easy enough to live with that setting off, I just wanted to crack the case!

Me too. I don't see how it can be related to anything other than that setting.
I'll try here with your client settings.

[Hendrik]

If automatic sync is off, and you hit the manual sync button, do you also see the increase?
The only thing that makes sense to even produce these amounts of memory is that process of building the database delta, but as said before, I have no idea why that would build up.

[mwillems]

If automatic sync is off, and you hit the manual sync button, do you also see the increase?
The only thing that makes sense to even produce these amounts of memory is that process of building the database delta, but as said before, I have no idea why that would build up.

I'm serving read-only from the server, so manually attempting to sync (using the "Sync changes to Library Server" button) just returns an error.

[Hendrik]

I'm serving read-only from the server, so manually attempting to sync (using the "Sync changes to Library Server" button) just returns an error.

Huh. Auto-Sync cannot work then either. I wonder if thats related to the problem. Sync for me always succeeded, of course.

[mwillems]

Huh. Auto-Sync cannot work then either. I wonder if thats related to the problem. Sync for me always succeeded, of course.

Doesn't auto-sync pull changes from the server to the client as well?   I thought it did, and that should still work in a read-only context, right?  If not, how are clients supposed to learn about changes in the server library?

I just tried testing with authentication, but my clients just seem to connect read-only automatically.  I can't seem to get the prompt for credentials on the client even after removing and readding the library.  Is there some secret to getting a prompt?

[Hendrik]

Doesn't auto-sync pull changes from the server to the client as well?   I thought it did, and that should still work in a read-only context, right?  If not, how are clients supposed to learn about changes in the server library?

It does that as well, but at least its another combination to test.

[bob]

Doesn't auto-sync pull changes from the server to the client as well?   I thought it did, and that should still work in a read-only context, right?  If not, how are clients supposed to learn about changes in the server library?

I just tried testing with authentication, but my clients just seem to connect read-only automatically.  I can't seem to get the prompt for credentials on the client even after removing and readding the library.  Is there some secret to getting a prompt?

Check the server settings, there are several authentication options there (read only, with auth, disabled).

[mwillems]

Ok, just tested with authentication enabled.  I still see memory growth on the client with authentication enabled, and manually syncing changes with the server produces the memory growth on demand as Hendrik predicted.