(2017-04-26 03:13)Kougami Wrote: After updating from #0418x to #0425, there is some problem with playback/free gpumem. Playing the testfile 4-5x and the free gpumem going down until Kodi is crashing.
bcmstat (#0425): https://pastebin.com/VFURdG9c
bcmstat (#0418x): https://pastebin.com/bNCyzuqi
testfile (~7mb): https://mega.nz/#!MuIUHLhC!Cwn93H22cK1UG...X49vhuHd2s (from Fune wo Amu)
Someone else the problem ?
I'm not seeing that behaviour here with #0425 and your sample.mp4 (played from SD card).
Can you test #0425 with a clean .kodi. How are you accessing your sample, local SD, smb:// or nfs://? What skin are you using?
The following is from an RPi3, with total_mem=1024 and gpu_mem=320 (same as yours), stock Estuary, 1080p/high colour depth artwork, playing your sample file from SD card:
Based on the above, what I see is that at the beginning of playback the GPU allocates 20.9MB of RAM (column "Delta GPU B"), of which 13.6MB is freed 4 seconds later, then at the end of playback 12.5MB is freed before another 5.2MB is allocated for use by the GUI. Once the 5.2MB is allocated at the end of playback the accumulated RAM usage by the GPU since the beginning of bcmstat.sh monitoring is 0 (zero) as shown in the column "Accum GPU B", meaning no memory leakage.
This is playing the sample file 6 times - accumulated GPU memory is always 0 at the end of each playback (the end of the 3rd play overlaps with the start of the 4th):
As I can't see any obvious GPU memory leakage, there must be some other difference between your system and mine.
Please test a "clean" .kodi installation as that's more or less what mine is. If you're using a third party skin maybe that is causing memory to leak by triggering some behaviour I'll never see with stock Estuary.
Also, can you identify the specific build when this problem first starts, as there's a week of builds between #0418x and #0425.