Ok, I played your file for 2 hours in a loop and there was just marginal change in memory usage. I then paused it for 1 hour where there was just small memory increases.
This was on a RPI2 with OMXplayer disabled and MMAL enabled
Memory usage log:
http://paste.osmc.io/ayuvixevox
I will now play it for another 2 hours with OMXplayer enabled.
Ok, with OMX player activated there seems to be a memory increase visible but it goes away after each time the video loops. So you might need to give us a longer piece to review this more in detail
So you’re saying that for you memory use only ever increases and doesn’t drop back down again on each repeat loop ?
I notice in your advancedsettings.xml you have loglevel set to 1 (debug logging but without the onscreen overlay) does it still leak memory if you remove that from advancedsettings.xml ?
Also have you checked to make sure that component specific debugging for video is turned OFF ? It is on by default due to a bug (but only if debugging in general is turned on) and this will generate large logs when playing video and could potentially be related. So please verify that with debug logging disabled that you still see a memory leak.
I ran your test clip in a loop for a while and for the first few repeats RES started at about 126484 and crept up to about 129436 during the playback of the clip, however it didn’t only increase during playback, it also dropped sometimes, and it went back to 126484 after each loop.
After a few loops the memory started hovering around 132388 during every loop:
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
381 osmc 20 0 570460 132388 41716 S 13.7 17.6 3:16.00 /usr/lib/kodi/kodi.bin --standalone -fs --lircdev /var/run/lirc/lircd
After a few more loops it dropped back to about 126484 again. So as far as I can see I’m not experiencing a memory leak playing this clip in repeat, although I’ll leave it playing for a while longer to be sure.
I don’t know if it’s important but I’m using omxplayer and I have the mpeg2 codec installed.
Keep in mind that RES is the “resident set size” of the executable which includes both memory for the executable code itself as well as certain types of memory allocations.
Portions of the Kodi binary that have not been executed will not be paged into memory and won’t contribute to the RES figure - when Kodi then executes some new code (such as that to play the video) that code gets paged into memory and expands the RES size. (As well as any buffers that Kodi mallocs)
Then when video stops the kernels memory manager may notice that certain pages of the Kodi executable are no longer being used and drop them from memory. (As their backing store is the executable file on disk, there is no need to page them out, or need for a swap file to do this, it simply drops the pages)
Whether this happens or not is outside the control of Kodi - it’s a decision that the Kernel makes based on memory pressure from other running processes, so this depends on what else is running on the system, but I suspect that’s why I sometimes see memory usage drop back after every loop and sometimes it lingers only to drop back a few loops later.
As long as there is no net growth over time this fluctuation of RES size is quite normal.
Another thought I have on the matter is that there are certain addons (which won’t be named…) that register for notifications when video playback stops and starts and run in the background when video is playing - it’s possible that one of these addons has a bug that is leaking memory.
To confirm this you would want to stop Kodi, move your .kodi directory out of the way then start Kodi again - this will give you a completely clean install with no skins or other addons installed - try your repeat test then and see if memory use still increases.
If it doesn’t, then it’s going to be either a skin bug or a bug in a service addon you have installed. It would be good if you could try the same repeat loop test on a clean install of Kodi like this, as the problem may be nothing to do with Kodi itself.
Thanks for looking into this. I’m too busy currently to provide a reasonably complete response immediately, but I’ll consider all your information and suggestions and I’ll try to get back to you on Thursday night (CET=UTC+1) with more information.
What I can confirm immediately is that I’ve taken these figures
from the first (1 minute) loop, subtracting free memory numbers read from the on-screen debugging display (this time using loglevel 2 and component debugging turned off).
I started and immediately paused playback before reading the first number to allow the system to settle after initialization and buffering, then continued playback and read the number at the end of the first loop. I did see small fluctuations in free memory numbers but I did not see them returning to previous levels after the first loop.
Please note that I’ve always played back the demo video from an SMB share, never locally.
For more information please stay tuned until Thursday. I’ll test it all over longer periods of time with an external RSS logging script on a clean Kodi installation. (BTW, I’ve written lots of C code on Unix-like systems in the old days, including application-level memory management stuff such as memory pool allocators, so I am aware of at least some of the intricacies involved.) Hopefully we’ll finally figure out what’s going on.
Thanks.
I would suggest trying the clean .kodi directory test first then when you get a chance, to immediately rule out addons as the culprit otherwise you could spend a lot of time trying to isolate a bug in kodi itself that only turns out to be a buggy addon. 
Unfortunately addons are responsible for a lot of the problems that Kodi can have including hangs on exit (quite common) complete Kodi crashes (sad face crash) as there is not much of a “sandbox” in Kodi’s python implementation, and service addons in particular can pretty much do what they want including running persistently in the background, so the chances of a memory leak in a badly written service addon are quite high.
@holgerd: I think you and @Oliver_O have slightly different although somewhat related issues.
Are you still having these problems ? If so, can you try editing the following file:
/etc/sysctl.d/osmc.conf
Try editing the following line:
vm.min_free_kbytes=12288
Change the number to 16384, save then reboot. See if you still get these freezes. If you do, try increasing it to 20480. If that doesn’t help put it back to 16384 then try editing the following line:
vm.swappiness=20
Try changing it to 80 and see if that helps.
@fzinken, @DBMandrake: Here’s a first set of results from several experiments using this monitoring script.
I’ve tried two video files with several settings on my regular Kodi installation:
Zapp.2015-12-09.23-20.ts is a 48 minute video (1.5 GB)kodi-memleak-demo-2015-12-14-22.31.mpg is our familiar demo video, played in a loopColumns are: date, time, RSS.
Zapp.2015-12-09.23-20.ts via SMB, MMAL, no debugging
2015-12-18 00:15:17 102328
2015-12-18 00:16:17 105716
2015-12-18 00:17:17 107792
2015-12-18 00:18:17 110196
2015-12-18 00:19:17 112308
2015-12-18 00:20:18 114684
2015-12-18 00:21:18 113836
Zapp.2015-12-09.23-20.ts via SMB, OMX, no debugging
2015-12-18 00:23:32 107292
2015-12-18 00:24:32 112776
2015-12-18 00:25:32 115592
2015-12-18 00:26:32 118456
2015-12-18 00:27:32 120536
2015-12-18 00:28:32 123068
kodi-memleak-demo-2015-12-14-22.31.mpg via SMB, MMAL, no debugging
2015-12-18 00:38:50 100356
2015-12-18 00:39:50 100600
2015-12-18 00:40:50 100628
2015-12-18 00:41:50 100568
2015-12-18 00:42:50 100552
2015-12-18 00:43:50 100460
2015-12-18 00:44:51 100480
2015-12-18 00:45:51 100676
kodi-memleak-demo-2015-12-14-22.31.mpg via SMB, OMX, no debugging
2015-12-18 00:47:29 103192
2015-12-18 00:48:29 106396
2015-12-18 00:49:29 107736
2015-12-18 00:50:29 103976
2015-12-18 00:51:29 106196
2015-12-18 00:52:30 108192
2015-12-18 00:53:30 108516
kodi-memleak-demo-2015-12-14-22.31.mpg via SMB, MMAL, debuglevel 2
2015-12-18 00:56:22 100192
2015-12-18 00:57:22 100844
2015-12-18 00:58:22 101128
2015-12-18 00:59:22 101104
2015-12-18 01:00:22 101088
2015-12-18 01:01:22 101056
2015-12-18 01:02:22 101084
2015-12-18 01:03:22 101060
2015-12-18 01:04:22 101468
kodi-memleak-demo-2015-12-14-22.31.mpg via SMB, OMX, debuglevel 2
2015-12-18 01:06:28 108176
2015-12-18 01:07:28 107540
2015-12-18 01:08:28 110008
2015-12-18 01:09:28 110240
2015-12-18 01:10:28 111172
2015-12-18 01:11:28 111688
2015-12-18 01:12:28 111680
So it seems that the demo loop shows RSS fluctuations, but doesn’t leak memory. (I’ve made sure that component debugging was turned off at all times.)
The longer video file shows steadily increasing RSS, which probably shouldn’t happen even if the memory were freed again after playback (I did not yet test this).
I’ll try to come up with a more compelling test case and I’ll test that with a clean .kodi directory as well. As soon as I have this ready, I’ll try the changes to /etc/sysctl.d/osmc.conf as suggested. However, it’ll probably take a couple of days (maybe even a week) until I find sufficient time to spend on this. I’ll get back to you as soon as possible.
Okay, I increased vm.min_free_kbytes to 16384 in /etc/sysctl.d/osmc.conf and rebooted the Pi. I’ll let you know how the system performs.
Update 1: Upping to 16384 kb didn’t help. Now testing with 20480 kb.
Update 2: No, 20480 kb was no good, either. Switching back to 16384 and setting vm.swappiness to 80.
Update 3: That also did not help.
I had this happen twice yesterday. Once it recovered on its own. The 2nd time, it didn’t recover until I unplugged the power to my network switch and plugged it back in. It then fast forwarded to a point in the future and started playing. This is a pi 1 playing mkv over nfs
I have this issue with my PI1 over nfs too!
in my fstab:
192.168.1.X:/volume1/multimedia/ /home/osmc/multimedia nfs4 nolock,rsize=16384,wsize=16384,intr,timeo=800,x-systemd.automount 0 0
Any fix yet? Should I downgrade?
Thanks, but saying “me too” doesn’t help diagnose the problem. (Nor does downgrading)
If you’re serious about trying to help solve it, please try the suggestions I made earlier like monitoring memory usage with top until the freeze occurs - we still don’t even know for sure if this is a low memory issue or not and won’t know until more people provide actual hard data.
Let me know how I can do that? Actually, I tried to see the logs but as the pi freeze, it seems it’s not saved.
I’m tring this, I’ll let you know if it freeze less often.
vm.min_free_kbytes=20480
vm.swappiness=80
It seems like this has been difficult to diagnose via logs. Unfortunately my background isn’t in linux programming; is there a way to do a differential between the August release, and the release where this is believed to have begun?
I’m having an issue with freezing while streaming over nfs as well, and I can understand that we need people to help diagnose the issue. The difficulty for a lot of folks is that this has broken the ability to watch tv and/or movies, and an immediate fix (like downgrading) is a better solution than trying to debug the issue.
I tried to ssh at the time it was frozen and it would not connect. I checked journalctl at the time of the freeze and there was nothing there. I understand what I provided isn’t terribly helpful but I don’t know what else I can provide since I can’t get any of the requested data. I had it happen again yesterday and unplugging the switch and rep lugging cleared the issue again without having to restart the pi. It’s no the switch since 2 other devices on same switch were still working. Next time I will just pull network cable to see if that does that fixes it as well.
So if you did get it running without a restart why didn’t you just upload the complete logs grab-logs -A?
Also helps if you would have debugging enabled (you can switch off the on screen display via advancedseetings.xml
Hello, I actually tried this to edit the file: /etc/sysctl.d/osmc.conf
as @DBMandrake say
And reboot
It seems it fix the issue, In any case it help that’s for sure. I’ll let you know if it freeze again.
Anyone else can confirm?
Many thanks’ @DBMandrake
@flori4n, you’ll see in my previous post that the first two suggestions did not work for me. Did you also set vm.swappiness=80?
I think different people are experiencing two different problems that may appear to cause the same symptoms - that’s why we need to see the top statistics to see if the system is actually running out of memory or not. (in which case the VM tweaks won’t help)
However there can be cases where the system is not really out of memory but behaves like it is, in this case the VM tweaks may help.
Actually, it freeze again. But this is happening way less often than before.
There’s the logs when it’ freeze, but i’m not sure that’s help. let me know if I can try something.
19:06:47 197988.843750 T:3025433136 NOTICE: DVDPlayer: Opening: /home/osmc/multimedia/tvShows/#### ## ####/Season 9/#####-####HDTV-720p.mkv
19:06:47 197988.843750 T:3025433136 WARNING: CDVDMessageQueue(player)::Put MSGQ_NOT_INITIALIZED
19:06:47 197988.843750 T:2557473824 NOTICE: Thread DVDPlayer start, auto delete: false
19:06:47 197988.843750 T:2557473824 NOTICE: Creating InputStream
19:06:47 197988.906250 T:2557473824 NOTICE: Creating Demuxer
19:06:47 197989.109375 T:2557473824 NOTICE: Opening stream: 0 source: 256
19:06:47 197989.187500 T:2557473824 NOTICE: Creating video thread
19:06:47 197989.187500 T:2557473824 NOTICE: Opening stream: 1 source: 256
19:06:47 197989.187500 T:2565862432 NOTICE: Thread OMXPlayerVideo start, auto delete: false
19:06:47 197989.187500 T:2557473824 NOTICE: Creating audio thread
19:06:47 197989.203125 T:2530210848 NOTICE: Thread OMXPlayerAudio start, auto delete: false
19:06:47 197989.296875 T:2557473824 NOTICE: OMXClock using audio as reference
19:06:48 197989.359375 T:2565862432 NOTICE: Display resolution DESKTOP : 1920x1080 (1920x1080) @ 60.00 - Full Screen (16)
---------------------- Kodi Old Log END --------------- 2qaAc90c
This is not a complete log.
Without complete logs, we cannot determine the issue. If you are serious about resolving this issue, I would follow the guidelines mentioned previously in this thread.