•   
  • 1
  • 61
  • 62
  • 63(current)
  • 64
  • 65
  • 304
  •   
v18 -  LibreELEC Testbuilds for RaspberryPi (Kodi 18.0)
(2017-02-10, 23:23)Milhouse Wrote:
(2017-02-10, 06:47)tonytoronto Wrote: I've been running the latest builds on Pi2 and i have had very little problems. Received my new pi3 today, installed Libreelec from Noobs screen, updated to the latest version (0209) and have problem with installing add-on from zip. When i click the icon,nothing happens. I know this was working on the pi2 with version few days older. I ended up going to original build on noobs and was able to install add-ons from zip, updated to 0209 the add-ons are installed and working but i cannot install new ones. Anyone else having this problem?

"Install from zip file" via the Add-ons home screen widget has always been broken in stock Estuary - nothing has changed with this recently.

You need to drill into Add-ons, navigate to the add-on browser ("box" icon) then click on "Install from zip file".

Thank You.
I ended up switching skins and installed the add-on.
v18 looking good, thank you.
Reply
(2017-02-10, 23:47)bmonster Wrote:
(2017-02-10, 23:30)Milhouse Wrote:
(2017-02-10, 15:56)popcornmix Wrote: Presumably:
Code:
Drop jemalloc, switch to MALLOC_MMAP_THRESHOLD_=512KB

I didn't notice this. Anyone else seeing this issue?
Milhouse, is it possible to manually disable this setting o 0206 just to be sure this is the culprit.

The environment variable has no effect on RPi2 as it only affects 64-bit systems. With #0205 I did apply jemalloc to both 32-bit/64-bit systems (ie. it was applied to RPi/RPi2) but now with #0206 we have dropped jemalloc and switched to applying the environment variable but only for 64-bit systems. So as far as RPi/RPi2 is concerned #0204 and #0206 should be the same.

Just tries 0204 on my rbp3 and im also seeing high memory usage, the same as 0206, within a couple of minutes its in the high 80s, and the system becomes really unresponsive.
But for some reason with 0205 it can be used all night and never goes above 50%, i will post some logs if you think theyll he!p.

Kind regards

Bucky

I need to backtrack slightly on my original reply. In #0206 we dropped the jemalloc package added in #0205, and instead applied Environment=MALLOC_MMAP_THRESHOLD_=524288 for all systems. In #0207 this was further restricted to 64-bit systems. Therefore #0204 and #0207 should be the same, while #0205 and #0206 although not identical should be similar (different solution to the same memory fragmentation problem).

If you are seeing a problem with #0204 and #0206 but not #0205 then adding "MALLOC_MMAP_THRESHOLD_=524288" in the latest build is not going to help - it sounds like only the jemalloc package solves your problem.

Can you explain what you are running on your system and if a "clean" .kodi helps? Perhaps a particular add-on is causing this issue.
Texture Cache Maintenance Utility: Preload your texture cache for optimal UI performance. Remotely manage media libraries. Purge unused artwork to free up space. Find missing media. Configurable QA check to highlight metadata issues. Aid in diagnosis of library and cache related problems.
Reply
(2017-02-11, 03:29)J_E_F_F Wrote: I had some RPis get fried on a wired lan connection, so I am changing everything over to wireless connections.

This really isn't a good idea. Wireless is never the best option for a media centre.
Reply
(2017-02-11, 05:52)Milhouse Wrote:
(2017-02-10, 23:47)bmonster Wrote:
(2017-02-10, 23:30)Milhouse Wrote: The environment variable has no effect on RPi2 as it only affects 64-bit systems. With #0205 I did apply jemalloc to both 32-bit/64-bit systems (ie. it was applied to RPi/RPi2) but now with #0206 we have dropped jemalloc and switched to applying the environment variable but only for 64-bit systems. So as far as RPi/RPi2 is concerned #0204 and #0206 should be the same.

Just tries 0204 on my rbp3 and im also seeing high memory usage, the same as 0206, within a couple of minutes its in the high 80s, and the system becomes really unresponsive.
But for some reason with 0205 it can be used all night and never goes above 50%, i will post some logs if you think theyll he!p.

Kind regards

Bucky

I need to backtrack slightly on my original reply. In #0206 we dropped the jemalloc package added in #0205, and instead applied Environment=MALLOC_MMAP_THRESHOLD_=524288 for all systems. In #0207 this was further restricted to 64-bit systems. Therefore #0204 and #0207 should be the same, while #0205 and #0206 although not identical should be similar (different solution to the same memory fragmentation problem).

If you are seeing a problem with #0204 and #0206 but not #0205 then adding "MALLOC_MMAP_THRESHOLD_=524288" in the latest build is not going to help - it sounds like only the jemalloc package solves your problem.

Can you explain what you are running on your system and if a "clean" .kodi helps? Perhaps a particular add-on is causing this issue.


Morning Milhouse,

When I have a problem, i'll leave it a couple of day and see if it disappears on its own, if it doesn't I'll always check the problem still exists under a clean environment, basically rename the .kodi folder.
I've gone back and tried all builds from 0201 to 0210, and for me the only one that's not screwing with the memory is 0205, every other build is giving high memory usage with minutes of booting.

Sorry I'm not too technical, so not sure how to investigate further, I can help further with a little guidance.

Regards BM
Reply
Seems like my issue when cec loses link after rebooting i solved by disabling cec initial active source (hdmi_ignore_cec_init). I used Leopold's RPi config addon to do it.
Reply
(2017-02-11, 14:08)MONSTA Wrote: Seems like my issue when cec loses link after rebooting i solved by disabling cec initial active source (hdmi_ignore_cec_init). I used Leopold's RPi config addon to do it.

Are your kodi CEC settings defaults? i.e. is "Switch source to this device on startup" enabled?
Reply
(2017-02-11, 14:14)popcornmix Wrote: Are your kodi CEC settings defaults? i.e. is "Switch source to this device on startup" enabled?
No. It's disabled. Also disabled next line "enable device on startup"
Reply
(2017-02-11, 14:29)MONSTA Wrote: No. It's disabled. Also disabled next line "enable device on startup"

That is not the default. Why would you disable it and then complain that TV doesn't switch to kodi?
That would be the requested behaviour.

Click the "Defaults" button in CEC settings and then only change settings you really need to.

(and add hdmi_ignore_cec_init back in - having cec announced with two different names has been known to confuse some TVs)
Reply
(2017-02-11, 14:43)popcornmix Wrote: Why would you disable it and then complain that TV doesn't switch to kodi?
That would be the requested behaviour.
I don't need switch to Kodi. Kodi already switched. The issue was that cec connection is lost after rebooting.
I disabled that lines in settings long time ago and everything worked fine.
Quote:Click the "Defaults" button in CEC settings and then only change settings you really need to.

OK. I'll try. Thanks.
Reply
(2017-02-11, 15:41)MONSTA Wrote: I don't need switch to Kodi. Kodi already switched. The issue was that cec connection is lost after rebooting.
I disabled that lines in settings long time ago and everything worked fine.

That option sends an active source which both switches to kodi and informs TV of the Pi being a connected CEC device.
Some TVs require that message to automatically forward button presses. Otherwise you have to manually enable each time.
Reply
I have another lockup of Kodi. Please look here: http://forum.kodi.tv/showthread.php?tid=...pid2522886

It shouldn't be about pvr.mythtv addon this time.
Reply
(2017-02-11, 15:25)raptorjr Wrote: Sorry for making so much trouble. But I have another Kodi lockup situation. Sometimes it happens the first time, sometimes I need to do it a few times.
I almost finished a recording and then skipped beyond the end, Kodi lockup. Needed to reboot through SSH.
But easy to replicate with just starting a recording and skip beyond the end. Maybe need to try a few times, but pretty consistent.

Don't know if it the addon or Kodi. But every time I post a problem elsewhere they say it is a addon problem. So this time I start here =)

Here is the log: http://sprunge.us/BFRC

Probably another PVR deadlock. Can you try to catch a backtrace? When it is locked up, run
Code:
killall -SEGV kodi.bin
and then post the new crashlog that appears in .kodi/temp.
Reply
(2017-02-11, 18:58)popcornmix Wrote: Probably another PVR deadlock. Can you try to catch a backtrace? When it is locked up, run
Code:
killall -SEGV kodi.bin
and then post the new crashlog that appears in .kodi/temp.

Here: http://sprunge.us/GbJf

Didn't have debug enabled. Can make another if that is necessary.
Reply
(2017-02-11, 13:49)bmonster Wrote: Morning Milhouse,

When I have a problem, i'll leave it a couple of day and see if it disappears on its own, if it doesn't I'll always check the problem still exists under a clean environment, basically rename the .kodi folder.
I've gone back and tried all builds from 0201 to 0210, and for me the only one that's not screwing with the memory is 0205, every other build is giving high memory usage with minutes of booting.

Sorry I'm not too technical, so not sure how to investigate further, I can help further with a little guidance.

Regards BM

Can you post your config.txt?

Also can you run "bcmstat.sh Zxd 10" in ssh after booting the latest build, as this should give a memory usage figure I can relate to. Leave it running and see if the memory usage figure increases to an abnormally high level.

My RPi3 with 320MB GPU split (booted last night about 9pm, so over 20 hours ago) currently shows:
Code:
Memory Free/Used
================
596,568 kB/15.2%

Once memory usage increases significantly, try running "top -o RES" which should list processes in descending order of memory usage.

Since this doesn't appear to be a new problem, and happens with a "clean" .kodi, I'd expect this to be far more widespread. I currently suspect this is something specific to your configuration, but not sure what that could be.
Texture Cache Maintenance Utility: Preload your texture cache for optimal UI performance. Remotely manage media libraries. Purge unused artwork to free up space. Find missing media. Configurable QA check to highlight metadata issues. Aid in diagnosis of library and cache related problems.
Reply
New LibreELEC.tv Leia build #0211: RPi / RPi2
(Supercedes previous build)

Code:
# uname -a
Linux rpi512 4.9.9 #1 Sat Feb 11 22:42:23 GMT 2017 armv6l GNU/Linux

# vcgencmd version
Feb  8 2017 19:38:24
Copyright (c) 2012 Broadcom
version d61adb766e5712326bba636c81017fbac3b8419f (clean) (release)

# lsb_release
LibreELEC (Milhouse) - Version: devel-20170211224117-#0211-g2c59d7d [Build #0211]

# Kodi version
(18.0-ALPHA1 Git:4c792db). Platform: Linux ARM 32-bit

Based on tip of LibreELEC.tv master (2c59d7d4, changelog) and tip of XBMC master (cbfa9649, changelog) with the following modifications: Build Highlights:
  1. Unmerged PR:1313 (config scripts for Wolfson/Cirrus Logic audio card) converted to package
Build Details:
  1. XBMC:
    • Improve keyboard handling during button mapping (PR:11645, 3 commits, 109 files changed)
  2. libnfs:
    • Fix the Windows cross build (PR:171, 3 commits, 2 files changed)
  3. kernel 4.9.y:
    • New commits in this build:
Texture Cache Maintenance Utility: Preload your texture cache for optimal UI performance. Remotely manage media libraries. Purge unused artwork to free up space. Find missing media. Configurable QA check to highlight metadata issues. Aid in diagnosis of library and cache related problems.
Reply
  •   
  • 1
  • 61
  • 62
  • 63(current)
  • 64
  • 65
  • 304
  •   
 
Thread Rating:
  • 12 Vote(s) - 4.67 Average



Logout Mark Read Team Forum Stats Members Help
LibreELEC Testbuilds for RaspberryPi (Kodi 18.0)4.6712