[Milhouse]

What I am getting is if I play the attached file, which was created with handbrake, nothing fancy I don't think.
https://www.dropbox.com/s/i1xq6n68lgtskw...s.mkv?dl=0
Starting with about 30% memory usage, after playing it twice, I'm up to 50%, 4 times 70%, 6 times 85%, soon after it'll lock up.

I confirm the issue, there is definitely a memory leak. After each viewing, the kodi.bin process will use more and more memory until LE completely locks up.

Yes there does appear to be an ARM RAM leak but I haven't been able to reproduce it with my normal h265 test videos, only with the Elysium video from bleep42. And if you play it often enough, kodi.bin will be OOM killed.

If you run (in one of my builds) bcmstat.sh -ADZ you can monitor the GPU and ARM memory allocations. Each time the Elysium video is played it leaks over 70MB of ARM RAM (build #0124) - ARM RAM appears to be leaking at the rate of about 1-2MB/s.

I went back and tested builds from 30, 60 and 90 days ago (back to #1023) and they all appear to have this same leak issue, so it's not a recent introduction.

I noticed that the kernel log (with #0124, not sure about older builds) is filling up with these messages during h265 playback (the messages stop at the end of playback):

Code:

Jan 25 01:26:20 rpi22 kernel: [clean_invalid_contiguous_mem_2d]: size cannot be 0

It appears to be logging 24 messages per second (one per frame?) during Elysium playback.

However this could be a red herring/unrelated, as I'm seeing this message logged continuosly when testing my own h265 videos (eg. eg. Big Buck Bunny 1080p x265 ts). Nothing is logged during h264 videos.

First play of Elysium - about 95MB of ARM RAM is not returned at the end of playback:


During playback you can see that additional ARM RAM (3rd from last column, "Mem kB") is being allocated ever 2 seconds, but rarely if ever freed. At the end of playback 76MB is freed, but this is less than the total accumulated 171MB ARM RAM allocated during playback, leaving the 95MB deficit.

At the end of the second play, 204MB ARM RAM had gone missing...


During the 9th play-through of Elysium, the system (Pi3B, 320MB gpu_mem, 704 ARM RAM, no overclocking, RPF white PSU) froze and bcmstat.sh reported:


which shows that 51MB ARM RAM remained available, and 513MB of ARM RAM had been apparently leaked.

[Milhouse]

It's possible there _is_ a memory leak when testing Big Buck Bunny 1080p H265 TS (just one example test video), about 10MB-20MB ARM RAM isn't freed when playback is ended after about 30 seconds (so after 3 plays the ARM RAM deficit is about -60MB), however it's significantly less of a leak than Elysium, and since this isn't an exact science it may be totally normal...

[bleep42]

Hi Milhouse & Popcornmix,
I did try going back myself and have found that from 0619x to 0801x seem to be ok, initially jumps to about 50% memory usage, but stabilises around 45%. The major leek starts in 0808x, so somewhere between 02/08/17 and 09/08/17, if that helps you.

I also use a Slice as my actual media centre I realise it is an old version of Kodie 8.2.2 Kernel 4.9.59, but it does seem to have most of the HEVC improvements, except 10bit. It plays the file in a loop fine.
Needless to say I've been using this file and variations on it at different bit rates for ages, to test the HEVC improvements over time, I only noticed the leak when I was playing it in a loop to stress the CPU to test clock setting. :-(
Such is life.....
Regards, Kevin.

[popcornmix]

Hi Milhouse & Popcornmix,
I did try going back myself and have found that from 0619x to 0801x seem to be ok, initially jumps to about 50% memory usage, but stabilises around 45%. The major leek starts in 0808x, so somewhere between 02/08/17 and 09/08/17, if that helps you.
 

#0805 had some hevc changes - can you confirm if that build introduced the leak?

[bleep42]

Hi Milhouse & Popcornmix,
I did try going back myself and have found that from 0619x to 0801x seem to be ok, initially jumps to about 50% memory usage, but stabilises around 45%. The major leek starts in 0808x, so somewhere between 02/08/17 and 09/08/17, if that helps you.

#0805 had some hevc changes - can you confirm if that build introduced the leak?   

Hi Popcornmix,
No, it seems to be between 0805 and 0806? in that 0805 is good, 26% to 37% memory usage while playing.
0806 is bad, up to 70% after a few plays, where I stopped it before it locked up.
Thanks for looking into this. :-)  I realise that using this high a quality, sort of defeats the object of HEVC, I only generated them to stretch your new HEVC improvements. ;-)
Regards, Kevin

[popcornmix]

No, it seems to be between 0805 and 0806? in that 0805 is good, 26% to 37% memory usage while playing.
0806 is bad, up to 70% after a few plays, where I stopped it before it locked up.

Nothing in that change log looks likely. There is a compiler bump but that would be quite a surprising culprit.
Milhouse do you see the same?

[rellik8821]

Hey,
How to create a squashfs Image with Last Build for Berryboot?

[Milhouse]

Hey,
How to create a squashfs Image with Last Build for Berryboot?

Berryboot isn't supported by LibreELEC - use NOOBS/PINN if you want to multi-boot.

And your question isn't relevant for this thread.

[asavah]

No, it seems to be between 0805 and 0806? in that 0805 is good, 26% to 37% memory usage while playing.
0806 is bad, up to 70% after a few plays, where I stopped it before it locked up.

Nothing in that change log looks likely. There is a compiler bump but that would be quite a surprising culprit.
Milhouse do you see the same? 

glibc bump could have something to do, it may be worth looking in https://sourceware.org/git/?p=glibc.git;....26/master there might be stuff worth cherry-picking,
there are quite a bunch of malloc fixes eg. like https://sourceware.org/git/?p=glibc.git;...998f74983c

[Milhouse]

No, it seems to be between 0805 and 0806? in that 0805 is good, 26% to 37% memory usage while playing.
0806 is bad, up to 70% after a few plays, where I stopped it before it locked up.

Nothing in that change log looks likely. There is a compiler bump but that would be quite a surprising culprit.
Milhouse do you see the same?

0805 definitely has a leak - this is after 2 plays of Elysium, showing 37MB deficit (end of 1st play) and then 115MB deficit (end of 2nd play):


0804 after 2 plays of Elysium, showing a small deficit (possibly not a leak) of 35MB (end of 1st play) and then 26MB (end of 2nd play):


I repeated playback with 0804 and the deficit is (mostly) increasing with each play of Elysium:

Code:

3rd playback:  45MB
4th playback:  50MB
5th playback:  95MB
6th playback:  69MB (deficit reduced)
7th playback:  62MB (deficit reduced)
8th playback: 135MB (large deficit increase/leak)
9th playback: 113MB (deficit reduced)

So 0804 may have a leak (not 100% sure, as it's harder to provoke) but it's not as significant as 0805.

[bleep42]

Hi Milhouse,
That sort of ties with what I see, but now try 0806 & it gets significantly worse.
So a possible small leak in 0804/0805 & previous, but then I see 0806 go catastrophic,  ie after 5 or 6 plays, it's running low on memory.
Regards, Kevin.

[Milhouse]

New LibreELEC.tv Leia build #0125: RPi / RPi2
(Supercedes previous build)

SHA256 Checksum: 6f632d2c45a1567daa4e325d641883ba60bc51643a0cb65c73e8e9871fe8d942 (RPi)
SHA256 Checksum: b491d7159fe683eab41630fac3ffd4c617337d5f57ac0744e2939b4ec61aac6d (RPi2)

text:
# uname -a

Linux rpi512 4.14.15 #1 Thu Jan 25 21:55:55 GMT 2018 armv6l GNU/Linux



# vcgencmd version

Jan 25 2018 18:14:16 

Copyright © 2012 Broadcom

version 16ab01397c559d80e3239c4d9c453a999a9121b1 (clean) (release)



# lsb_release

LibreELEC (Milhouse): devel-20180125214619-#0125-g3a70864 [Build #0125]



# Kodi version

(18.0-ALPHA1 Git:69a6725). Platform: Linux ARM 32-bit

Based on tip of LibreELEC.tv master (3a70864, changelog) and tip of XBMC master (7379a75, changelog) with the following modifications:

• Includes newclock5 patches
  
• Excludes the LibreELEC linux-01-RPi_support patch in favour of sourcing these and possibly more recent patches directly from kernel branch rpi-4.14.y
  
• Includes latest bcm2835-driver master (80e1fbe, ahead +5)
  
• Includes latest kodi-platform master (36fb493)
  
• Includes latest libcec master (8adc786, ahead +26)
  
• Includes latest libnfs master (f6e51c3, ahead +115)
  
• Includes latest p8-platform master (a822e19)
  
• Includes latest addons: inputstream.adaptive (b28d3f0, +1), inputstream.rtmp (b3ffc49, +2), peripheral.joystick (0a20d01), pvr.argustv (a4d3ec7), pvr.demo (0224cbd), pvr.dvblink (4ac2f2d), pvr.dvbviewer (c2275e1), pvr.filmon (e754b4b), pvr.hdhomerun (7379fbc), pvr.hts (774943f), pvr.iptvsimple (a00d008), pvr.mediaportal.tvserver (0c5ece3, +1), pvr.mythtv (3200b09), pvr.nextpvr (11dfdbb), pvr.njoy (67b837d), pvr.octonet (689afbf), pvr.pctv (c7a13d7), pvr.stalker (c91421d), pvr.teleboy (3ae0297), pvr.vbox (24126fd), pvr.vdr.vnsi (4db947c), pvr.vuplus (020e1d2), pvr.wmc (920ade6), pvr.zattoo (fed0aea), vfs.libarchive (568a2a1)
  
• Include [env] compare (perma): dmidecode: initial package
  
• Include [env] patch: RPi/RPi2: enable Broadcom WiFi debugging (see details)
  
• Include [env] patch: libcec: fix PR390
  
• Include [env] patch: libcec: don't link non-existant libtinfo
  
• Include [env] patch: rev hack for kodi
  
• Include [env] patch: HACK: Disable multiple PVR addons during migration. Always enable inputstream.* and os.*
  
• Include [env] patch: Add experimental splash video for RPi
  
• Include [env] patch: Bump included addon versions to prevent online updates
  
• Include [env] patch: Add kodi binary addons (pvr, adsp, inputstream, vfs, other)
  
• Include [env] PR:2243 (perma): NOOBS: shorten partition labels, add $DEVICE support
  
• Include [env] PR:2382 (perma): linux: DVB fixes
  
• Include [env] PR:2384 (perma): kodi: updates for Feb 2018
  
• Include [env] PR:2392 (perma): linux: update to linux-4.14.15 (-ish)
  
• Include [env] PR:2432 (perma): buildsystem: avoid if/then/else boiler plate when accessing hierarchy [RFC]
  
• Include [env] PR:2438 (perma): curl: update to curl-7.58.0
  
• Include [pkg] compare (perma): Updated RPi3/ZeroW(H) WiFi firmware (version 7.45.98.38) (forum, github) (brcmfmac_sdio-firmware-rpi)
  
• Include [pkg] patch: skin.estuary: reduce system info font size (kodi)
  
• Include [pkg] PR:13274 (perma): Mode whitelist
  
• Include [pkg] PR:13416 (perma): [GLES] VideoShader cleanup
  
• Include [pkg] PR:13435 (perma): Fix broken ctrl+shift modifiers
  

Build Highlights:

1. New firmware (Refactor get/set_voltage API, add SDRAM voltage)
   
2. New 4.14.15 kernel
   
3. curl: update to curl-7.58.0
   
4. [GLES] updates and cleanup
   
5. [GLES] VideoShader cleanup
   
6. newclock5 branch cleanup
   
7. Fix broken ctrl+shift modifiers (@TimoJ)
   

Build Details:

1. Firmware (Jan 25):
   • firmware: power: Refactor get/set_voltage API, add SDRAM voltage
     
2. LibreELEC.tv:
   • scripts/create_addon: add-on overwrite support (PR:2436, 1 commit, 1 file changed)
     
3. XBMC:
   • [cmake] move ifdef conditions to cmake (PR:13430, 1 commit, 10 files changed)
     
   • [cleanup] remove dead code POPUP_SEEK_LABEL (PR:13431, 2 commits, 1 file changed)
     
   • [Android] disable tunneled playback (PR:13426, 1 commit, 1 file changed)
     
   • [depends] improve rebuilding detection (PR:13436, 10 commits, 54 files changed)
     
   • [AML] define MESA_EGL_NO_X11_HEADERS to detect correct egl_platform (PR:13425, 1 commit, 2 files changed)
     
   • FIX: [droid;gradle] override aaptOptions (PR:13437, 1 commit, 1 file changed)
     
   • [GLES] updates and cleanup (PR:13406, 1 commit, 3 files changed)
     
   • [xbmc] move Environment to platform and split to platform specific implementations. (PR:13424, 3 commits, 18 files changed)
     
   • [gui] cleanups in WindowManager especially for getting the active window and dialog id (PR:13433, 5 commits, 23 files changed)
     
4. inputstream.adaptive:
   • [depends] bump expat to 2.2.5 (PR:114, 1 commit, 3 files changed)
     
5. newclock5:
   • New commits in this build:
     • filesystem: test: Reduce chunksize to 64K (cce72c4b)
       
     • fixup! [videoplayer] Add logging of message queue levels (8425ddf9)
       
   • Updated commits in this build:
     • ffmpeg: Automatic switch to software decode for GMC with more than one warp point (218f02b2 => 38da0b64)
       
     • ffmpeg: use upstream mvc patches (8c297630 => 5416678e)
       
   • Commits no longer in build:
     • StereoscopicsManager: Wait for valid stream info before triggering stereo mode (8da32d4e)
       
     • fixup: CStereoscopicsManager reduce logging spam (12e8fb58)
       
     • fixup ffmpeg patches (19b22e11)
       
     • filesystem: set proper check size for smb (2e0297f8)
       
     • ffmpeg: hevc: Update to latest version (23b7803f)
       
     • filesystem: test: Reduce chunksize to 32K (d4764573)
       
     • hack: Don't assert when unexpected buffer id but keep going (33bf6f01)
       
     • filesystem: test: Increase chunksize to 64K (84fe3321)
       
     • Revert "fixup: CStereoscopicsManager reduce logging spam" (53c863bc)
       
     • Revert "StereoscopicsManager: Wait for valid stream info before triggering stereo mode" (c76386ba)
       
     • Revert "fixup ffmpeg patches" (2ac5c6cd)
       
     • ffmpeg: Restore GMC patch (e89a622d)
       
     • ffmpeg: Restore MVC patch (e9012b39)
       
6. kernel 4.14.y:
   • New commits in this build:
     • drm/vc4: Use correct path to trace include (76c964d4)
       
     • drm/vc4: clean up error handling on devm_kzalloc failure (55728644)
       
     • drm/vc4: Add the DRM_IOCTL_VC4_GEM_MADVISE ioctl (2c9c1ddf)
       
     • drm/vc4: Fix false positive WARN() backtrace on refcount_inc() usage (c7723901)
       
     • drm/vc4: Fix sleeps during the IRQ handler for DSI transactions. (a4a82dbb)
       
     • drm/vc4: Convert timers to use timer_setup() (b0114216)
       
     • drm/vc4: Account for interrupts in flight (d32f7ada)
       
     • drm/vc4: Move IRQ enable to PM path (8d011ade)
       
     • drm/vc4: Fix wrong printk format in vc4_bo_stats_debugfs() (295267e2)
       
     • drm/vc4: Reject HDMI modes with too high of clocks. (abb187e7)
       
     • drm/vc4: Add support for DRM_FORMAT_RGB888 and DRM_FORMAT_BGR888 (ab068dd0)
       
     • drm/vc4: Use .pixel_order instead of custom .flip_cbcr (70a1d4ce)
       
     • drm/vc4: Add support for NV21 and NV61. (e6c8ad2e)
       
     • BCM270X: Disable VEC unless vc4-kms-v3d is present. (f55396cb)
       
     • drm/vc4: Flush the caches before the render jobs, as well. (85e4adfb)
       
7. Additional commits/pull requests/changes not yet merged upstream:
   • Updated: [env] PR:2392 (perma): linux: update to linux-4.14.15 (-ish)
     
   • Added: [env] PR:2438 (perma): curl: update to curl-7.58.0
     
   • Added: [pkg] PR:13416 (perma): [GLES] VideoShader cleanup
     
   • Added: [pkg] PR:13435 (perma): Fix broken ctrl+shift modifiers
     

[Milhouse]

Hi Milhouse,
That sort of ties with what I see, but now try 0806 & it gets significantly worse.
So a possible small leak in 0804/0805 & previous, but then I see 0806 go catastrophic,  ie after 5 or 6 plays, it's running low on memory.
Regards, Kevin.

With #0806 the deficit is is 76MB at the end of first playback, 144MB at end of 2nd, and - not shown - 213MB at end of 3rd:


To me this looks more like #0805 than #0804, but it's hard to say if #0806 is worse than #0805 - I'd probably say they're much the same, and that the problem starts with - or is made worse (a small leak becoming a much bigger leak) by - #0805.

The only major change in #0806 is the gcc/glibc bump but hopefully they're not involved, as that would be a major task to track down...and wouldn't really explain why this affects only HEVC playback and not any other video codec.

[bluenote]

I just installed this running #0125, and the netflix plugin.  On my Pi2 the playback is out of sync, even if I disable dolby in the netflix addon.  Not all cpu's are heavily used, however. 
I do have another pi that has codecs bought for it, is it necessary and expected to need that?  

I'm not sure if I screwed up the version of libwidevine, because I used the script at one point, because apparently if you miskey your credentials to the netflix addon, you don't get an opportunity to fix it, and I wasn't sure the source of my issue at that point.  So how do I make sure I'm using the latest widevine?  The wiki for the netflix addon only lists a page for firefox that doesn't seem to have a PI version listed.   Where can I find the helper addons if this isn't already included in the netflix addon?

Otherwise, are there typical changes to make performance better?  I haven't overclocked this test unit, for example.

Thanks for any advice, sorry for the newbie questions.  I did read the wiki's and faq's as much as possible.

[Milhouse]

I just installed this running #0125, and the netflix plugin.  On my Pi2 the playback is out of sync, even if I disable dolby in the netflix addon.  Not all cpu's are heavily used, however. 
I do have another pi that has codecs bought for it, is it necessary and expected to need that?  

It's software only decode with Netflix (and Amazon) so no need for codec licences.

Not sure about the sync issue, haven't really watched any Netflix stuff for a while myself.

Where can I find the helper addons if this isn't already included in the netflix addon?

I'd suggest starting a thread in the add-ons sub-forum - supporting Widevine is outside the scope of this thread and probably now deserves one of it's own particularly as the old widevine library no longer works with Amazon, and newer versions of the widevine library are crashing Kodi on RPi.

Otherwise, are there typical changes to make performance better?  I haven't overclocked this test unit, for example.

A small overclock to CPU frequency might help. Overclocking in general has been discussed many times in this thread and in other threads in the Raspberry Pi sub-forum.

Limiting max resolution to 720p in inputstream.adaptive is likely to result in the best performance - due to the software decoding the RPi2/3 can't really do 1080p.