More > JRiver Media Center 23 for Linux

Suspected Memory Leak in Linux Builds

<< < (2/4) > >>

mwillems:

--- Quote from: bob on April 05, 2018, 12:24:36 pm ---Trying to repro it.
Did you use lsof to check for the hung sockets?
Are you using any of the other client options like audio transcoding?

--- End quote ---

I tried it both with and without transcoding.  Orignal files were FLAC and transcoding to medium quality mp3 seemed to slow the leak somewhat, but otherwise had no effect.  I used netstat -p tcp to observe the sockets, I'll try lsof when testing tomorrow.  It's not a subtle leak during playback, on my amd64 system which has 16Gb of ram, MC will be using 30 or 40% of the ram after three or four hours of playback.

mwillems:
So testing on my main (non-pi) machine. I'm not seeing the hung sockets (that may have just been an artifact of the pi's lame-o networking), but the memory leak is definitely there and turns on or off depending on the auto sync with server setting.  The memory leak seems to increase by (more or less) the size of the file played; every file played increases the memory usage by roughly its size.  There's also the slow leak over time too even at idle.  One odd thing I noticed which may or may not be a clue: when I tried toggling auto-sync with server from on to off during playback I saw really odd behavior.  The currently playing song kept playing, but the stop button wouldn't stop it (even though the MC UI showed the song as stopped).  Playing another song resulted in both playing at once and the UI successfully controlled playback for the second song only.  Weird. 

Here's a diff of the lsofs in the two states during playback (autosync on is the first argument to diff, autosync off is the second argument to diff):


--- Code: ---   COMMAND     PID    USER   FD      TYPE             DEVICE  SIZE/OFF     NODE NAME

< mediacent 10278 michael  DEL       REG                0,5             111650 /memfd:pulseaudio
---
> mediacent 10278 michael  DEL       REG                0,5             110720 /memfd:pulseaudio
7c7
< mediacent 10278 michael  DEL       REG                0,5              57022 /memfd:pulseaudio
---
> mediacent 10278 michael  DEL       REG                0,5             108267 /memfd:pulseaudio
139c139
< mediacent 10278 michael   19u     IPv4             109974       0t0      TCP *:52199 (LISTEN)
---
> mediacent 10278 michael   19u     IPv4              57139       0t0      TCP *:52199 (LISTEN)
140a141
> mediacent 10278 michael   21u     IPv4             110672       0t0      TCP Neptunian:52199->living_room.system:57196 (ESTABLISHED)
142d142
< mediacent 10278 michael   23u      REG              259,6  23664205  3145755 /home/michael/.jriver/Media Center 23/Temp/BufferedInternetReader - 2663028480-0.dat.cnk
143a144
> mediacent 10278 michael   28u      REG              259,6  18722850  3145755 /home/michael/.jriver/Media Center 23/Temp/BufferedInternetReader - 3437180672-0.dat.cnk
147,151c148,152
< mediacent 10278 michael   32r      REG              259,6  23664205  3145755 /home/michael/.jriver/Media Center 23/Temp/BufferedInternetReader - 2663028480-0.dat.cnk
< mediacent 10278 michael   33r     FIFO               0,12       0t0    57019 pipe
< mediacent 10278 michael   34w     FIFO               0,12       0t0    57019 pipe
< mediacent 10278 michael   35r     FIFO               0,12       0t0    57020 pipe
< mediacent 10278 michael   36w     FIFO               0,12       0t0    57020 pipe
---
> mediacent 10278 michael   32r      REG              259,6  18722850  3145755 /home/michael/.jriver/Media Center 23/Temp/BufferedInternetReader - 3437180672-0.dat.cnk
> mediacent 10278 michael   33r     FIFO               0,12       0t0   108264 pipe
> mediacent 10278 michael   34w     FIFO               0,12       0t0   108264 pipe
> mediacent 10278 michael   35r     FIFO               0,12       0t0   108265 pipe
> mediacent 10278 michael   36w     FIFO               0,12       0t0   108265 pipe
153c154
< mediacent 10278 michael   38u     unix 0x00000000926fb9fb       0t0    57023 type=STREAM
---
> mediacent 10278 michael   38u     unix 0x00000000ba652056       0t0   108268 type=STREAM

--- End code ---

Of note: turning auto-sync off stops the growth in memory usage, but does not release any memory previously built up with auto-sync on, and I took the lsof of auto-sync off after auto-sync on, so the total memory usage was larger than when I took the auto-sync on lsof snapshot.  Let me know if I can provide any other useful info (or clean lsofs right after opening MC or something).

craigmcg:
Quote from Bob

"Interesting. I wonder if it's an issue in the Mac and Windows builds as well."

I can't say that it is for sure but when I turned off Auto synch on the client PCs (all running Win 10 x64), the library server on the server PC stopped the crashing that has been bugging me for months (first thought that it was network switch related then Win 10 networking changes, etc.). While I only made the change yesterday I haven't had the crash on the server PC since (was happening a few times each day). I have 5-6 client PCs connecting to the server using the Library server.

Thanks to Bob and mwillems for pointing me to what seems to be the solution.

mattkhan:
FWIW I have 2 separate linux machines connected to a windows server, I do have that option checked and I don't see any evidence of a socket leak

bob:
Are any of you using Last.FM updating?

Navigation

[0] Message Index

[#] Next page

[*] Previous page