Hi, thanks for reply but as said above this command like top does not seem to have reliable info. I mean I tried it but I see processes that uses too low memory.
I do not think it is useful in my situation. I am already very close to out of memory even in normal situation. Now I only have to determine what processes/addosn remove to resolve the issue.
Guys I really appreciate your help. I think I can manage this evening the issue installing some commands like htop or try something else, at the end it should not be complicated. I think I can solve this by myself. For addon I can remove all the things I do not need (I really installed too much useless stuff with several pirate plugins that are not so useful for italian people) and try to save memory with try/error.
Thanks again everyone for support. I appreciated it a lot.
If you really need to free up some memory try this in /boot/config.txt
gpu_mem=160
Alternaticly use MyOSMC, Pi Config, GPU mem & Codec.
This should be sufficient for running Kodi and playing HD content within it, but it’s a temporary fix, fix the underlaying problem. I’m not sure if OSMC has greater demands for GPU mem then a Raspian running kodi.
Do you have evidence to support your notion that top and ps return unreliable data? Most linux tools for process monitoring, including graphical ones, get there data in the same way (many by running top and ps and then outputting them in a fancy graphical wrapper.
I’m not sure you fully understand how linux deals with memory. Whilst 25MB is a relatively low amount of free memory, you would not run out of memory were 25MB more to be used, as there is also cached memory which could be freed up to manage demand.
I suggest you may find the most productive way to manage your problem would be to uninstall the pirate add-ons, enable debug logging and then wait for kodi to crash. When it recovers examine both kodi.log and kodi.log.old and you will likely find your culprit with ease.
I am doing some test. Playing a movie in local I noticed that with free the memory (initially at 200 Mb) is decreased until reach almost 26 Mb while cached raise to 483216 more or less.
considering I have a Raspberry Pi 2 Model B do these value make sense. My goal here when I configured this stuff is only to have streaming playing smoothly. After that setting I must say that streaming was quite good. I followed a tutorial on the web. I remember that tutorial suggested the following:
check the free memory on the system and assign 1/3 of this in bytes to cachemembuffersize. Does this make sense?
Do you suggest I delete the advancesetting.xml file.
I have to say that before this change sometime I experienced issues in buffering and this settings seems solve the problem?
Is there a compromise here (i.e. 40 or 60 Mb)?
Hi,
It was for KODI in general and not specific for OSMC/Raspberry if I well remember. I have the link but after few months it is not available anymore and the main website is redirected to another website now. This is what I remember. To be honest I do not know if the website was reliable I just found the tutorial looking for keywords on google and found it. That’s what I remember. You are right it could be also possible that buffermode and readbufferfactor solved the issue.
Regarding buffermode it only mean to apply the setting when streaming from Internet, so I do not know if it could improve the performance here in my case. I do not know if readbufferfactor helped. Today I read on the web that this value should be between 1 and 4, do you think 5 is too big?
However, I’ll do some tests playing with this value, the main problem is that the issue is not systematic but random.
Ok, I know this documentation. In fact it is reported:
Note: For the memory size set here, Kodi will require 3x the amount of RAM to be free.
Probably I overestimated the quantity of free RAM on my Raspberry. Probably it is not 500Mb. I do not remember if I took this value from KODI Information System page or from ssh shell. I can check better this value and then set cachemembuffersize to VALUE/3. However, I should also check if leaving this at 20 Mb the other two parameters solve the issue.
Of the tens of thousands of OSMC users that we support, we never recommend anyone change cachemembuffersize to anything other than the default <cachemembuffersize>20971520</cachemembuffersize>