2018-01-27, 08:48
2018-01-27, 10:01
(2018-01-27, 09:43)polo_joe Wrote: Osd in livetv works again in #0126b.Confirmed. All buttons are working again in LiveTV
Thx!
2018-01-27, 10:30
(2018-01-27, 01:27)Milhouse Wrote: LiveTV OSD users - please test build #0126b: RPi2Everything is fine for me
This includes PR:13444 which hopefully fixes the OK/Select remote control issue.
2018-01-27, 12:46
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
2018-01-27, 14:06
(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).
2018-01-27, 14:39
(2018-01-27, 14:06)popcornmix Wrote:Hi Popcornmix & Milhouse,(2018-01-27, 05:52)Milhouse Wrote: I'm not sure how low we want to go withMALLOC_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).
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.
2018-01-27, 15:51
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!
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!
2018-01-27, 20:42
(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.
2018-01-28, 00:27
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?
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?
2018-01-28, 06:13
New LibreELEC.tv Leia build #0127: RPi / RPi2
(Supercedes previous build)
SHA256 Checksum:
SHA256 Checksum:
Based on tip of LibreELEC.tv master (56b38d5, changelog) and tip of XBMC master (e1e969b, changelog) with the following modifications:
(Supercedes previous build)
SHA256 Checksum:
f446d479999e404ed37154324f9914f61a4506161fc3070ddb30308faa78bad8
(RPi)SHA256 Checksum:
0d6fdf55926a576a0e36ccff9afe02b768a95f342cb08580a052dfd78f614488
(RPi2)text:# 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:
- 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): kodi: reduce arm memory fragmentation
- 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:2432 (perma): buildsystem: avoid if/then/else boiler plate when accessing hierarchy [RFC]
- Include [env] PR:2442 (perma): mesa: update to mesa-17.3.3
- 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:13435 (perma): Fix broken ctrl+shift modifiers
- Fix LiveTV OSD issue with OK remote button
- kodi: reduce arm memory fragmentation (8KB)
- 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)
- add -J flag to limit race condition during build step (PR:2445, 1 commit, 1 file changed)
- 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)
- Fix crash on exit. (PR:13445, 1 commit, 15 files changed)
- Additional commits/pull requests/changes not yet merged upstream:
2018-01-28, 06:37
(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.