[fritsch]

Short term: Add more memory :-)

There is a memory leak somewhere. Don't know perhaps LE wants to experience with zram :-) to at least gracefully exit / restart when kodi starts to eat memory.

[moontan77]

Ok thanks, was hoping somehow that kernel log pointing to source of leak

[Milhouse]

We identified one OOM starting with build #0807 (it happens real quick on an RPi!). It's triggered by seeking when passthrough is enabled. There are a couple of audio-related PRs in #0807 that might be responsible: http://forum.kodi.tv/showthread.php?tid=...pid2398048

[Milhouse]

@ Milhouse/Fritsch

since build #0823 my system is a bit slow.
Using a Zotac ID41 (intel atom d525 with ion2).
navigating the library is sluggish and the rss feed stutters.
playing 1080p content is fine but the processor load seems to have more than doubled during playback,
normally it totals at 60% but since @0823 it goes as high as 160% (same video)
when i look at the system info i noticed that the processor speed (normally always at 1800 MHz) now goes down to as low as 225 MHz (AFAIK atom d525 has no idle states nor speedstep).
going back to #0822 and all is fine again

debug log #0823 - http://sprunge.us/RcXG

idling for about 5 min. at system info screen after a reboot.

We switched to the newer 4.7 "schedutil" governor in the 4.7.2 bump (introduced build #0823), I wonder if that's causing more sluggish performance than the older ondemand governor?

https://github.com/LibreELEC/LibreELEC.t...8b3e128336

I will revert the governor change in tonigh'ts build - let me know if it's worse/same/better.

[wizziwig]

I think you should go the Ubuntu route for debugging this - I can build you whatever kernel you want, after you are ready and working with: http://forum.kodi.tv/showthread.php?tid=231955

Thanks for trying to help. I figured Ubuntu would have been the best approach as well. Unfortunately, the little mini-pc that I have hooked up to the buggy TV has very little storage (30GB SSD) that is mostly occupied by Windows 10. I was booting LibreElec from USB flash drive. I"ll try to figure something out to get more space on there.

I've been running Ubuntu from a VirtualBox image on another PC in order to make my own LibreElec builds for testing. I was able to successfully test a few of my own ideas as well as some patches from Intel. Intel's patches didn't help (other than turning off 36-bit color support which I can easily do via custom EDID).. My own code changes did fix the audio bug with 36-bit color still enabled but left other issues that still need to be resolved (a/v clock mismatch causing frame skipping).

I've dealt with HDMI configuration bugs on another embedded platform but the Intel hardware is a bit different and more complicated because of multiple pipes (HDMI, DP, etc.). Hardware documentation is also poor.

I think the main reason many Intel bugs don't get fixed for years is because the end-users who report them are usually not developers and can't verify fixes. Building custom kernels, etc. is too much for most people so they just give up after reporting the bug.

[Milhouse]

New LibreELEC.tv Krypton build #0826: Generic
(Supercedes previous build)

Code:

# uname -a
Linux NUC 4.7.2 #1 SMP Fri Aug 26 22:27:08 BST 2016 x86_64 GNU/Linux

# lsb_release
LibreELEC (Milhouse) - Version: devel-20160826222340-#0826-ga0e3207 [Build #0826]

Based on tip of LibreELEC.tv master (a0e32078, changelog) and tip of XBMC master (a56be148, changelog) with the following modifications:

• Includes FernetMenta "VideoPlayer" patches
  
• Includes latest kodi-platform master (c8188d82)
  
• Includes latest libcec master (62b8520c, ahead +15)
  
• Includes latest libnfs master (fac3a954, ahead +34)
  
• Includes latest p8-platform master (041a8c6c, ahead +1)
  
• Includes latest addons: inputstream.mpd (7898a672), inputstream.rtmp (9c05b8dd), inputstream.smoothstream (b63ecbb4), peripheral.joystick (ff088653, +25), pvr.argustv (299088b5), pvr.demo (01c68c88), pvr.dvblink (ea3d98cc), pvr.dvbviewer (f72c62ff), pvr.filmon (675c2b4e), pvr.hdhomerun (eef1bd15), pvr.hts (48b2e261), pvr.iptvsimple (a4c52558), pvr.mediaportal.tvserver (1042a71c), pvr.mythtv (b1b426f3), pvr.nextpvr (4dabcf41), pvr.njoy (b5d65655), pvr.pctv (d6d969fe), pvr.stalker (bb9c0b10, +10), pvr.vbox (2750c92a), pvr.vdr.vnsi (40c45dc9), pvr.vuplus (7ab30d34), pvr.wmc (d9eac84f)
  
• Includes commits from xbmc/master, ahead +5 (FernetMenta)
  
• Exclude [env] kodi-999.99-PR10309.patch: merged upstream
  
• Exclude [env] libcec-PR208.patch: Merged upstream
  
• Include [env] patch: Add kodi binary addons (pvr, adsp, other)
  
• Include [env] patch: Don't build ADSP addons
  
• Include [env] patch: Bump included addon versions to prevent online updates
  
• Include [env] patch: Add experimental splash video for RPi
  
• Include [env] patch: HACK: Disable multiple PVR addons during migration. Always enable inputstream.* and os.*
  
• Include [env] PR:535: init: Add upgrade check to avoid incompatible upgrades [RFC,WIP]
  
• Include [env] PR:641: kodi: update to 17.0-beta1-81d5d26
  
• Include [env] PR:657: ffmpeg: add indev x11grab_xcb
  
• Include [env] PR:663: image: fakeroot chokes on image names with meta chars
  
• Revert [env] 46b9b7b3: rtmpdump (Reason: use newclock5 bump)
  
• Revert [env] PR:910a3f1b904b26c535e1826f0987268b3e128336: Generic/RPi2: Switch to schedutil CPUFreq governor (reverted: might result in sluggish performance)
  
• Include [pkg] 441217d8: logging: Add microsecond timer to log messages (kodi)
  
• Include [pkg] patch: drm/i915: Fixes and diagnostics for Braswell (linux)
  
• Include [pkg] patch: [skin.estuary] Hide watched items on home (kodi-theme-Estuary)
  
• Include [pkg] patch: drm/i915: Limit the depth of the display pipeline to the framebuffer (linux)
  
• Include [pkg] PR:8645: [video] Add season/TV show artwork to episodes/seasons even if they have their own fanart.
  
• Include [pkg] PR:8824: videodb: fix smart playlists not honoring "Show empty TV shows" setting.
  
• Include [pkg] PR:8922: [guiinfo] extend ranges for listitem properties
  
• Include [pkg] PR:10157: [WIP] Double the backslash in mysql in case we're in 'LIKE'
  
• Include [pkg] PR:10325: [estuary] - show buffering progress in video full screen
  
• Include [pkg] PR:10335: skin migration and addon compatibility checking
  

Build Highlights:

1. Revert to ondemand governor from schedutil
   
2. Updated peripheral.joystick Deadzone settings
   
3. Intel: Chris Wilson patch to avoid using higher bitdepths than required. Insufficient bandwidth may be responsible for signal loss and blank displays. See bug.
   

Build Details:

1. LibreELEC.tv:
   • Odroid_C2: 64_bit_omx_pts (c108863c)
     
   • linux: update Odroid_C2 kernel to 365fa20 and tweak config (b4277bf0)
     
   • init: mount per-client boot/disk if available & configured (#621) (a0e32078)
     
2. XBMC:
   • Deadzone settings (PR:10309, 7 commits, 20 files changed)
     
3. peripheral.joystick:
   • Remove deadzone setting (PR:48, 1 commit, 4 files changed)
     
4. Additional commits/pull requests/changes not yet merged upstream:
   • Exclude [env] kodi-999.99-PR10309.patch: merged upstream
     
   • Added: [env] PR:657: ffmpeg: add indev x11grab_xcb
     
   • Added: [env] PR:663: image: fakeroot chokes on image names with meta chars
     
   • Reverted: [env] PR:910a3f1b904b26c535e1826f0987268b3e128336: Generic/RPi2: Switch to schedutil CPUFreq governor (reverted: might result in sluggish performance)
     
   • Added: [pkg] patch: drm/i915: Limit the depth of the display pipeline to the framebuffer (linux)
     

[Milhouse]

@ Milhouse/Fritsch

since build #0823 my system is a bit slow.
Using a Zotac ID41 (intel atom d525 with ion2).

Please compare #0823, #0825 and #0826 and see which you prefer.

[mglae]

We identified one OOM starting with build #0807 (it happens real quick on an RPi!). It's triggered by seeking when passthrough is enabled. There are a couple of audio-related PRs in #0807 that might be responsible: http://forum.kodi.tv/showthread.php?tid=...pid2398048

Reverting

- VideoPlayer: passthrough fixes (PR:10247, 1 commit, 1 file changed)

fixes the OOM in my private LE build.

[fritsch]

@wizziwig: Please check the nightly build, milhouse included the 8bpc patch chris wilson posted.

[jan-g]

@ Milhouse/Fritsch

since build #0823 my system is a bit slow.
Using a Zotac ID41 (intel atom d525 with ion2).

Please compare #0823, #0825 and #0826 and see which you prefer.

definitely #0826, speeds are back to normal.
just to give you an idea about the speed differences,
#825 15 sec. to bring up my Movie Db, vs #826 11 sec. (big Db 14K+)
#825 4 sec to bring up LE configuration, vs #0826 less than a second.

interesting reading about "Schedutil" and :p-states", as I understand it, if the "CPUFreq governor, Schedutil" isn't enabled, then the "Intel P-State CPU frequency scaling driver" is at play.
While Schedutil is actively throttling my ancient (6 years+) Atom d525, p-state freq scaling has no effect on performance (isn't .throttling the freq.)
Seeing that Scheduti is doing an overall better job than p-state, it's only a matter of time it will be activated in the kernel.
So the big question is will Schedutil be always activated or is on demand activated the default.

[fritsch]

p-state is not used on your Atom at all.

And btw: Reverted: [env] PR:Commit:910a3f1: Generic/RPi2: Switch to schedutil CPUFreq governor (reverted: might result in sluggish performance) <- he reverted the schedutil change, which means p-state / or ondemand or whatever should be active for you again.

[Milhouse]

What is your default governor in #0826, is it "ondemand" or "performance", or something else? Check with "cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor".

It should be "ondemand", but my Revo (Atom D525) is using "performance" even though the default governor is configured as "ondemand". A Skylake-based NUC uses exclusively P-States rather than "schedutil" (when enabled) and enabling "schedutil" support should have no effect on more recent Intel hardware (as it will be ignored).

So if your hardware supports P-States then you'll use P-States as your governor. Otherwise your hardware will use CPUFreq "schedutil".

You can always change the governor by writing a value ("ondemand", "performance", "powersave") to "/sys/devices/system/cpu/cpu0/cpufreq/scaling_governor", eg. "echo ondemand > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor". This could be added in autostart.sh if you prefer that governor, although if schedutil is resulting in more sluggish performance then we can consider dropping it (though in theory, this shouldn't be the case).

[Milhouse]

schedutil change is now dropped.

[jan-g]

What is your default governor in #0826, is it "ondemand" or "performance", or something else? Check with "cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor".

it's performance.

I believe an ancient D525 has no advanced power savings whatsoever and as it has a Tdp of 14W there's no real need for it..
and if "schedutil change is now dropped" I'm a happy camper again.
thanks.

[Milhouse]

We'll try again with schedutil in 4.8.