[Gracus]

Hi,

First apologize if this thread is misplaced as I do not know if this issue is limited to Kodi 64 bits for windows or spread accross all kodi releases

Now my issue...

I tried to use advancedsettings.xml to set a 1GB cache
Was aware thanks to the wiki that I will use 3GB ram but do not really care as my rig has 32GB ram

So I put 1073741824 (1GB) as the cache value
Then I made a test and see that the cache maxed out at 384MB:



Here is the full log of this test: https://pastebin.com/fRjYZkwy

Found that a little bit weird and decided to triple the value to 3221225472 (3GB) to see if this time cache maxed out at about 1GB

Result was even weirder: this time I was not capable to launch a playback!
Everything refuse to play: movies, TVshows and music

Sometime I even got an error window:



Here is the full log of this second test: https://pastebin.com/zx5gRDxd

I also want to add that those test were made with local files on my hard drive

Any help or explanation on this issue?

[Gracus]

Do some more testing

Re-set the cache to 1073741824 and, while it brings back movies playback, I was still unable to play TVshows and music...

Then I remove cache settings from advancedsettings.xml and TVshows/music playback works

[Gracus]

Did one last test to try to find where the issue comes from: going back to yesterday's nightly (KodiSetup-20170515-077dbd9e3a-master) and setting cache back to 3GB

This time all playback were working (movies, TVshows and music) but cache seems to maxing out at 768MB:



So there seems to be two issues:

- one that is there since "I don't know when" : cache does not max out at the set value

- one that is there since today's nightly (KodiSetup-20170516-3db90c95c9-master) : setting a cache value "disable" playback of some files

[host505]

That's weird. If it were the 32bit version I would say that​ the problem is the limitation of 32bit applications to only use up to a specific amount of ram (2.5gb I think) but it's the 64bit build. Not sure if it's related.
An observation is that the cache amount seems to be scalable by some amount (384x2=768).
If you set memorysize at 1.5gb, does cache max out at 512MB?
Based on your tests it seems that memorysize specifies the ram amount that can be used, not the buffer. Buffer seems to be memorysize/3.

[Gracus]

That's weird. If it were the 32bit version I would say that​ the problem is the limitation of 32bit applications to only use up to a specific amount of ram (2.5gb I think) but it's the 64bit build. Not sure if it's related.
An observation is that the cache amount seems to be scalable by some amount (384x2=768).
If you set memorysize at 1.5gb, does cache max out at 512MB?
Based on your tests it seems that memorysize specifies the ram amount that can be used, not the buffer. Buffer seems to be memorysize/3.

I check just to be sure and I did not make mistake when downloading it: it is the 64 bits build

Just try your suggestion and if I set memorysize to 1.5GB, then cache maxes out at 576MB

I came to the same conclusion for the relation between memorysize, ram amount and buffer but here is what is in the kodi wiki:

Value: 20971520 (or any value, in bytes) - keep the cache in RAM, but increase how much RAM is used. The number is the buffer size in bytes (20971520 is the default, which is 20MB, which requires 60MB of free RAM). Kodi will not buffer ahead more than this. Note: For the memory size set here, Kodi will require 3x the amount of RAM to be free. Setting this too high might cause Kodi to crash if it can't get enough RAM.

According to the wiki, if I set memorysize to 1GB it should set the buffer to 1GB and use 3GB of ram

[host505]

Yeah I know, that's why I pointed it out.
I wonder how it behaves with kodi 16 and prior, where memorysize used to be cachemembuffersize. Maybe along with the command naming the function changed also.

[Gracus]

Seems like I will have to wait for a dev to come to this thread...

[ashlar]

Edit: Nope, I'm wrong, sorry.

[scott967]

That's weird. If it were the 32bit version I would say that​ the problem is the limitation of 32bit applications to only use up to a specific amount of ram (2.5gb I think) but it's the 64bit build. Not sure if it's related.
An observation is that the cache amount seems to be scalable by some amount (384x2=768).
If you set memorysize at 1.5gb, does cache max out at 512MB?
Based on your tests it seems that memorysize specifies the ram amount that can be used, not the buffer. Buffer seems to be memorysize/3.

Just a clarification. For 32 bit apps on windows, there is no particular limitation on the use of RAM. There is, however, a concept of virtual memory (sometimes written VAS for virtual address space) which is a flat, 32-bit space that is allocated by windows via memory "commits". For 32-bit Windows OS, that 32-bit address space is further restricted, as apps are only allowed to allocate 2 Gb of that (IOW, 31 bits). The remaining 2 Gb is reserved for windows OS that must run in the app's address space (a big chunk of this typically is graphics memory). It is possible (again in 32-bit windows) to modify this via the LARGEADDRESSAWARE switch, which requires setting a flag in the app's exe file header. In this case, the app can allocate 3Gb of the VAS. This can be further tuned via a boot switch USERVA which can set the commit limit to anything between 2 and 3 Gb.

This is for 32 bit windows. On 64 bit windows, 32 bit apps run under WoW64 which moves all the OS address space above the "4Gb limit" VAS space. So apps can use almost the full 4Gb VAS (app exe still needs LARGEADDRESSAWARE). I think ntdll.dll may still need some small amount of app VAS.

scott s.
.

[host505]

Just a clarification. For 32 bit apps on windows, there is no particular limitation on the use of RAM. There is, however, a concept of virtual memory (sometimes written VAS for virtual address space) which is a flat, 32-bit space that is allocated by windows via memory "commits". For 32-bit Windows OS, that 32-bit address space is further restricted, as apps are only allowed to allocate 2 Gb of that (IOW, 31 bits). The remaining 2 Gb is reserved for windows OS that must run in the app's address space (a big chunk of this typically is graphics memory). It is possible (again in 32-bit windows) to modify this via the LARGEADDRESSAWARE switch, which requires setting a flag in the app's exe file header. In this case, the app can allocate 3Gb of the VAS. This can be further tuned via a boot switch USERVA which can set the commit limit to anything between 2 and 3 Gb.

Thanks for these infos.

This is for 32 bit windows. On 64 bit windows, 32 bit apps run under WoW64 which moves all the OS address space above the "4Gb limit" VAS space. So apps can use almost the full 4Gb VAS (app exe still needs LARGEADDRESSAWARE). I think ntdll.dll may still need some small amount of app VAS.

scott s.
.

So, is kodi 32bit using that LARGEADDRESSAWARE? (or is it a parameter that user must set?) Because if not, problems like this will start to arise if cachemembuffersize/memorysize is set too high, forcing kodi to use the whole 2GB of VAS.
Also, what's the default allocated VAS of 64bit applications --if there is a limit at all?

[host505]

That's weird. If it were the 32bit version I would say that​ the problem is the limitation of 32bit applications to only use up to a specific amount of ram (2.5gb I think) but it's the 64bit build. Not sure if it's related.
An observation is that the cache amount seems to be scalable by some amount (384x2=768).
If you set memorysize at 1.5gb, does cache max out at 512MB?
Based on your tests it seems that memorysize specifies the ram amount that can be used, not the buffer. Buffer seems to be memorysize/3.

I check just to be sure and I did not make mistake when downloading it: it is the 64 bits build.

It just hit me: did you happen to use the KodiSetup-20170516-3db90c95c9-master build?
Because have a look at my last comment there.

[Gracus]

That's weird. If it were the 32bit version I would say that​ the problem is the limitation of 32bit applications to only use up to a specific amount of ram (2.5gb I think) but it's the 64bit build. Not sure if it's related.
An observation is that the cache amount seems to be scalable by some amount (384x2=768).
If you set memorysize at 1.5gb, does cache max out at 512MB?
Based on your tests it seems that memorysize specifies the ram amount that can be used, not the buffer. Buffer seems to be memorysize/3.

I check just to be sure and I did not make mistake when downloading it: it is the 64 bits build.

It just hit me: did you happen to use the KodiSetup-20170516-3db90c95c9-master build?
Because have a look at my last comment there.

Yep, was using this one

Will try with the one from today

[Gracus]

As pointed by host505, I just try with today's nightly (and check it was running in 64 bits)

Good news: the playback error does not happen anymore if I have a cache setting in advancedsettings.xml

Bad news: the issue with cache not maxing out at the value put in advancedsettings.xml is still there

Could be good to have someone from the team to tell if it is an issue they have to fix or if it is an issue in the wiki page about cache settings

[ashlar]

In my experience cache settings have always been problematic. Having switched to DSPlayer I'm lucky enough to have them work through LAV Filters Splitter correctly (not the Kodi settings, the filter has its own settings).
It's kind of bad because the level of configurability is really where it should be.
And now I feel guilty because I'm not testing them, being on DSPlayer

[host505]

I also did my own tests, with the same result, always buffered about 1/3 of what is set on advancedsettings.xml.
Strange thing is that this is true for kodi 18 64bit nightlies, 17.1 (win) and 16.1 (Android).
So I guess whether the wiki is wrong or something isn't working as expected, it has nothing to do with kodi 18, it has been like that for a long time.