•   
  • 1
  • 284
  • 285
  • 286(current)
  • 287
  • 288
  • 401
  •   
v18 -  LibreELEC Testbuilds for RaspberryPi (Kodi 18.0)
(2018-01-27, 08:25)polo_joe Wrote: Build #0126b can't be found, error 404.

Working here...
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
Was problem in mobile phone browser.
Osd in livetv works again in #0126b.
Reply
(2018-01-27, 09:43)polo_joe Wrote: Osd in livetv works again in #0126b.
Confirmed. All buttons are working again in LiveTV
Thx!
PC: Kubuntu 17.10 and Win7/10 --- Wetek Play: LibreELEC 8.2.2 as TVH-server --- RPi3: latest Milhouse 9.0 --- Orbsmart 500 with Kodi18 as Online-radio/TV in the kitchen
Reply
(2018-01-27, 01:27)Milhouse Wrote: LiveTV OSD users - please test build #0126b: RPi2

This includes PR:13444 which hopefully fixes the OK/Select remote control issue.
 Everything is fine for me
[1x RPi3]#[ AV Receiver - Marantz NR1506 ]#[ TV Panasonic TX-50EXW784 ]#[ NAS @ OMV 3.0.9x (Erasmus) on Banana Pi ]#[ ODROID C2 + wrxtasy's LE 8.0 ]
Reply
OK/Select remote control #0126 not OK, #0126b  OK
rPi 3 & 3B+, SanDisk Ultra 8Gb SD & Milhouse LE TestBuild (Kodi 18) -> Onkyo TX-SR608 ​AV Receiver​ -> Philips 42" LCD TV
Reply
Live TV OSD with 0126b,, All good, thank you..
Reply
Anyone else having issues with AC3 Pass-Through with these releases? My receiver has short outages in the sound, then redetects the 5.1 AC3 Encoding and everything is fine again. Happens every few minutes and only when pass-though is activated. Worked perfectly fine with Kodi 17
Reply
Same here
Reply
(2018-01-27, 05:52)Milhouse Wrote: I'm not sure how low we want to go with MALLOC_MMAP_THRESHOLD_ - a value of 8192 might be a usable value. I feel that going as low as 1024 might result in an excessive number of chunks for no real advantage. But that's all a bit finger-in-the-air.
  
Be aware that mallocs above the threshold are much more expensive (in arm CPU time), so a high threshold is beneficial for performance.
When John's back I'll check what ram gets dynamically allocated and whether any large allocations can be "pooled".

Feel free to add MALLOC_MMAP_THRESHOLD_ to subsequent builds for further testing, but personally I'd favour a slightly larger value (32K/64K) for performance.
But I guess having the smaller value for testing purposes may be interesting (if no one notices the difference then maybe it's not important).
Reply
(2018-01-27, 14:06)popcornmix Wrote:
(2018-01-27, 05:52)Milhouse Wrote: I'm not sure how low we want to go with MALLOC_MMAP_THRESHOLD_ - a value of 8192 might be a usable value. I feel that going as low as 1024 might result in an excessive number of chunks for no real advantage. But that's all a bit finger-in-the-air.
  
Be aware that mallocs above the threshold are much more expensive (in arm CPU time), so a high threshold is beneficial for performance.
When John's back I'll check what ram gets dynamically allocated and whether any large allocations can be "pooled".

Feel free to add MALLOC_MMAP_THRESHOLD_ to subsequent builds for further testing, but personally I'd favour a slightly larger value (32K/64K) for performance.
But I guess having the smaller value for testing purposes may be interesting (if no one notices the difference then maybe it's not important).  
Hi Popcornmix & Milhouse,
For the interested, (I design real time software for flight simulators) but uninitiated, if you have a spare moment, could you explain what you think is happening, I was always under the impression that when you malloc some memory, as soon as you do a free of that same memory, it's all returned? or is this a feature/bug in the latest compiler. I know what fragmentation is, but it would imply that there are lots of chunks of memory malloc'd which are hanging around, blocking subsequent mallocs, getting worse, each time the video (in this case) is played? or I don't understand. :-(
Regards, Kevin.
Reply
Since several builds I still receive kodi crashing when opening audio streams via yatse:
kodi.old.log
kodi_crashlog_20180127143845.log
I've reported long time ago, but it's still present, at least in build #0121
thanks and best regards!
Reply
(2018-01-27, 05:52)Milhouse Wrote: I've tested various values for MALLOC_MMAP_THRESHOLD_ (with #0126 on RPi3, gcc-7.2.0, glibc-2.26, gpu_mem=320MB, arm=704MB) and these are the results:
I tested with 8192 and 65536 and I don't see much difference compared to default. Kodi fills up the whole available RAM after ~ 8-12 runs. 8192 seem to be even worse that 65536.
Reply
I have an ongoing problem for probably 6 months or more. I stay pretty up to date with these builds, updating once or twice a week. I run a RP3, wireless WIFI, from a file server with a MySQL DB, and I play almost exclusively 720p HEVC content.

I'd estimate about 1 out of 8 times I rewind 4x or 8x speed to catch some audio I didn't hear right the first time maybe back 30 seconds or so, the display hangs and shows me a 100% icon when I switch from rewind to PLAY (image below)  It rewinds fine, it only happens when I hit the Play button. It never recovers by itself, and I can not FF/RW/PLAY/PAUSE etc, it just hangs, but I can push STOP and then choose to play/resume again, and when it does, it recovers back a minute or so.
I have done some lan speed (iperf) testing and everything is zooming right along.

I don't think this is a crash, so no crash log would be generated?
Any ideas?

Image
Reply
New LibreELEC.tv Leia build #0127: RPi / RPi2
(Supercedes previous build)

SHA256 Checksum: f446d479999e404ed37154324f9914f61a4506161fc3070ddb30308faa78bad8 (RPi)
SHA256 Checksum: 0d6fdf55926a576a0e36ccff9afe02b768a95f342cb08580a052dfd78f614488 (RPi2)

# uname -a
Linux rpi512 4.14.15 #1 Sun Jan 28 02:02:18 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-20180128020105-#0127-g56b38d5 [Build #0127]

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

Based on tip of LibreELEC.tv master (56b38d5, changelog) and tip of XBMC master (e1e969b, changelog) with the following modifications: Build Highlights:
  1. Fix LiveTV OSD issue with OK remote button
  2. kodi: reduce arm memory fragmentation (8KB)
Build Details:
  1. LibreELEC.tv:
    • add -J flag to limit race condition during build step (PR:2445, 1 commit, 1 file changed)
    • linux: update to linux-4.14.15 (-ish) (PR:2392, 21 commits, 14 files changed)
    • docker: depend on systemd (PR:2447, 1 commit, 1 file changed)
    • minidlna: initial addon (PR:2437, 1 commit, 12 files changed)
    • LibreELEC-settings: update to c8ec6f6 (PR:2450, 1 commit, 1 file changed)
  2. XBMC:
    • Fix crash on exit. (PR:13445, 1 commit, 15 files changed)
    • [fix] move virtual window handling to translators to solve issue with remote mappings (PR:13444, 1 commit, 6 files changed)
    • VideoPlayer: rewrite yuv to rgb conversion for OpenGL (PR:13428, 8 commits, 50 files changed)
    • [GLES] VideoShader cleanup (PR:13416, 5 commits, 40 files changed)
  3. Additional commits/pull requests/changes not yet merged upstream:
    • Added: [env] compare (perma): kodi: reduce arm memory fragmentation
    • Updated: [pkg] PR:13435 (perma): Fix broken ctrl+shift modifiers
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
(2018-01-27, 14:06)popcornmix Wrote: Be aware that mallocs above the threshold are much more expensive (in arm CPU time), so a high threshold is beneficial for performance.
When John's back I'll check what ram gets dynamically allocated and whether any large allocations can be "pooled".

Feel free to add MALLOC_MMAP_THRESHOLD_ to subsequent builds for further testing, but personally I'd favour a slightly larger value (32K/64K) for performance.
But I guess having the smaller value for testing purposes may be interesting (if no one notices the difference then maybe it's not important).

Yes, I thought there might be more CPU overhead when using smaller chunks. Elysium is playing OK with 8K but if there are problems then we can try larger chunks.

(2018-01-27, 14:39)bleep42 Wrote: Hi Popcornmix & Milhouse,
For the interested, (I design real time software for flight simulators) but uninitiated, if you have a spare moment, could you explain what you think is happening, I was always under the impression that when you malloc some memory, as soon as you do a free of that same memory, it's all returned? or is this a feature/bug in the latest compiler. I know what fragmentation is, but it would imply that there are lots of chunks of memory malloc'd which are hanging around, blocking subsequent mallocs, getting worse, each time the video (in this case) is played? or I don't understand. :-(
Regards, Kevin.

There is additional information if you follow the links in the original PR1286, in particular the bugzilla link.

(2018-01-27, 20:42)smp1 Wrote: I tested with 8192 and 65536 and I don't see much difference compared to default. Kodi fills up the whole available RAM after ~ 8-12 runs. 8192 seem to be even worse that 65536.

Are you sure you applied MALLOC_MMAP_THRESHOLD_ correctly? Can you re-test with #0127 (with 8192 threshold)?

I've briefly tested #0127 with 8192 and the deficit after...

1st playback: 15MB
2nd playback: 24MB
3rd playback: 29MB

which is broadly in line with my previous 8192 results (and significantly better than without any MALLOC_MMAP_THRESHOLD_).

Not enough time for 8 plays, need Zzz.
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
  • 284
  • 285
  • 286(current)
  • 287
  • 288
  • 401
  •   
 
Thread Rating:
  • 18 Vote(s) - 4.56 Average



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