• 1
  • 371
  • 372
  • 373(current)
  • 374
  • 375
  • 495
v18 LibreELEC Testbuilds for RaspberryPi (Kodi 18.0)
@aleksobs I'm suspicious about one of the firmware commits - the oldest build not including it is #0511 (https://forum.kodi.tv/showthread.php?tid...pid2734288) and the first with it is #0513 (sic) (https://forum.kodi.tv/showthread.php?tid...pid2734758).

I would be grateful if you could try both builds to see what happens to the USB ports at shutdown and report back.
New LibreELEC.tv Leia build #0531: RPi / RPi2
(Supercedes previous build)

SHA256 Checksum: 180b738a5cf38963b53b04700a5ddc8fa646b4987782149cb90655b74dcd6269 (RPi)
SHA256 Checksum: 4421975f225376ffcc06dc0927f6dab1e020366d297965db97c76955f2c9a60a (RPi2)

text:
# uname -a
Linux rpi512 4.14.44 #1 Thu May 31 21:07:05 BST 2018 armv6l GNU/Linux

# vcgencmd version
May 25 2018 14:36:49
Copyright © 2012 Broadcom
version 1d00025257e46ea069b2a0f59f0f443b2be2124e (clean) (release)

# lsb_release
LibreELEC (Milhouse): devel-20180531210348-#0531-g19b9bed [Build #0531]

# Kodi version
(18.0-ALPHA2 Git:795b10a). Platform: Linux ARM 32-bit

Based on tip of LibreELEC.tv master (19b9bed, changelog) and tip of XBMC master (57ca5a0, changelog) with the following modifications: Build Highlights:
  1. wireless-regdb: update to wireless-regdb-2018.05.31
  2. enable LTO only for selected packages
  3. NSS/NSPR update to 3.37.1/4.19
  4. stats: add GPU type to LibreELEC update check
Build Details:
  1. LibreELEC.tv:
    • libdrm: change to use meson and update (PR:2726, 4 commits, 1 file changed)
    • openssl: do not include from host (PR:2734, 1 commit, 1 file changed)
  2. XBMC:
    • Vector optimizations to make it "constexpr" (PR:13951, 5 commits, 4 files changed)
    • [osx] bump minimum version to 10.9 (PR:13949, 7 commits, 20 files changed)
    • [GUI] Prevent scrolling in Home menu for 8 entries (PR:13956, 1 commit, 1 file changed)
    • VideoPlayer: dxva - fix crash on some platforms. (PR:13959, 1 commit, 3 files changed)
  3. kernel 4.14.y:
    • New commits in this build:
  4. Additional commits/pull requests/changes not yet merged upstream:
    • Updated: [env] PR:2729 (perma): linux: update to linux-4.14.44
    • Added: [env] PR:2731 (perma): enable LTO only for selected packages
    • Added: [env] PR:2733 (perma): NSS/NSPR update to 3.37.1/4.19
    • Added: [pkg] PR:100 (perma): stats: Replace CPU 32/64 bit flag with GPU enumeration (service.libreelec.settings)
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.
(2018-05-31, 13:37)bleep42 Wrote: PS. I just tried the 10bit Jelly fish files and none of them will play past the first few frames, the play bar along the bottom continues but the picture freezes, #0530.
Personally I don't use, or see any dramatic improvement for 10bit, so I wouldn't normally test it.
Regards,
Kevin.

Excuse my ignorance, but I am a tad bit confused. Does this mean that 10 bit Hevc no longer works?
So 0526 is the first build with the recordings disappearing from the list.  

Log:
http://ix.io/1bZ6

Previously I watched a recording and when I pressed stop, the recording was no longer listed. That didn't always work for me. I also observed it while recording a show and navigating within Live TV (specifically, into Channels then Guide, then Recordings). As mentioned, Group Items is disabled.

Perhaps it's PR:13913. If so and it helps to reproduce, I'm using a shared database and the tvh server on an unraid server.
(2018-06-01, 05:59)doug Wrote: So 0526 is the first build with the recordings disappearing from the list.  

Log:
http://ix.io/1bZ6

Previously I watched a recording and when I pressed stop, the recording was no longer listed. That didn't always work for me. I also observed it while recording a show and navigating within Live TV (specifically, into Channels then Guide, then Recordings). As mentioned, Group Items is disabled.

Perhaps it's PR:13913. If so and it helps to reproduce, I'm using a shared database and the tvh server on an unraid server.


Known problem. Should be fixed with next build.

Was caused by https://github.com/xbmc/xbmc/pull/13931
(2018-06-01, 01:04)Double L Wrote:
(2018-05-31, 13:37)bleep42 Wrote: PS. I just tried the 10bit Jelly fish files and none of them will play past the first few frames, the play bar along the bottom continues but the picture freezes, #0530.
Personally I don't use, or see any dramatic improvement for 10bit, so I wouldn't normally test it.
Regards,
Kevin.

Excuse my ignorance, but I am a tad bit confused. Does this mean that 10 bit Hevc no longer works? 
I had a little look myself. 10bit HEVC still works with #530.
The file jellyfish-20-mbps-hd-hevc-10bit.mkv stuttered with build #513 and this possibly got a little bit worse with #530.
It seems like the ffmpeg4 performance regression was fixed only for 8-bit HEVC. There is still a performance decrease with 10-bit HEVC.
I tested builds #0424 and #0531 with jellyfish-10-mbps-hd-hevc-10bit.mkv.
Build #0424: 7-8 skipped frames.
Build #0531: 11-12 skipped frames.
(2018-06-01, 15:32)smp1 Wrote: It seems like the ffmpeg4 performance regression was fixed only for 8-bit HEVC. There is still a performance decrease with 10-bit HEVC.
I tested builds #0424 and #0531 with jellyfish-10-mbps-hd-hevc-10bit.mkv.
Build #0424: 7-8 skipped frames.
Build #0531: 11-12 skipped frames.
I find the skipped frame counts to be quite variable. Are you sure these measurements are repeatable over multiple runs?
It feels like they are within the normal variation.

(Note: the act of bringing up the OSD tends to cause some skips when it caches characters for a new font. We also report the skips/drops on playback end in the debug log. Do you see the same results there?)
(2018-05-31, 13:37)bleep42 Wrote: PS. I just tried the 10bit Jelly fish files and none of them will play past the first few frames, the play bar along the bottom continues but the picture freezes, #0530.
Personally I don't use, or see any dramatic improvement for 10bit, so I wouldn't normally test it.
10-bit is working for me, but it does require more processing so the maximum bitrate that can be played is lower. But I can play all the usual (non-bitrate stressing) encodes.
If you are overclocking does it behave differently without overclock?

Edt: Forgot to mention the obvious thing. 10-bit decode requires more gpu memory to decode.
Make sure gpu_mem is at least 320 if you want to play 10-bit 1080p video with many reference frames.
(2018-06-01, 15:37)popcornmix Wrote: I find the skipped frame counts to be quite variable. Are you sure these measurements are repeatable over multiple runs?
I just re-tested with a disabled VDR backend and this time I got more or less identical results. Looks like VDR running in the background slightly affected the results. Sorry for the noise.
(2018-06-01, 15:40)popcornmix Wrote:
(2018-05-31, 13:37)bleep42 Wrote: PS. I just tried the 10bit Jelly fish files and none of them will play past the first few frames, the play bar along the bottom continues but the picture freezes, #0530.
Personally I don't use, or see any dramatic improvement for 10bit, so I wouldn't normally test it.
10-bit is working for me, but it does require more processing so the maximum bitrate that can be played is lower. But I can play all the usual (non-bitrate stressing) encodes.
If you are overclocking does it behave differently without overclock?

Edt: Forgot to mention the obvious thing. 10-bit decode requires more gpu memory to decode.
Make sure gpu_mem is at least 320 if you want to play 10-bit 1080p video with many reference frames. 
Hi Popcornmix,
Yes it was the gpu_mem, I've added a comment to the config file to stop me reducing it. :-(
Sorry for the disturbance.
Kevin.
New LibreELEC.tv Leia build #0601: RPi / RPi2
(Supercedes previous build)

SHA256 Checksum: 66208620a6337868add092bb807a2f842ddfe4602ad94e9266374fa0d31b35ab (RPi)
SHA256 Checksum: 226c080d0c965dfa60fe698e056a254b9bc8ce53c48824ad2f7c1ff207b7ebcf (RPi2)

text:
# uname -a
Linux rpi512 4.14.44 #1 Fri Jun 1 21:06:29 BST 2018 armv6l GNU/Linux

# vcgencmd version
Jun 1 2018 14:05:47
Copyright © 2012 Broadcom
version 478d13bd2bb41a9c77c03d981a23b31e872b3683 (clean) (release)

# lsb_release
LibreELEC (Milhouse): devel-20180601210455-#0601-g19b9bed [Build #0601]

# Kodi version
(18.0-ALPHA2 Git:795b10a). Platform: Linux ARM 32-bit

Based on tip of LibreELEC.tv master (19b9bed, changelog) and tip of XBMC master (7831ed9, changelog) with the following modifications: Build Highlights:
  1. New firmware (fixes for borderline RPi3+ boards)
    popcornmix Wrote:We've tweaked avs and sdram settings to hopefully fix issues with some of the borderline RPi3+ boards.

    One change is we no longer add "sdram_schmoo=0x02000020" and "over_voltage_sdram_p=2" on a Pi3+ when sdram_freq > 450 (we do for older Pi's). If anyone with sdram overclock who doesn't explicitly set those reports a problem, then suggest adding them (one at a time).

    Another change is when overclocking sdram, we should really be increase the RL/WR values (read latency/write latency) which we will now do. It has a small effect on performance, but shouldn't affect a busy system much (other accesses can get in during the gaps).

    One other change with new firmware is the temperature threshold when we switch from 1.4GHz to 1.2GHz has been reduced from 70'C to 60'C. This may produce some reduction in performance when chip is hot, but it makes some of the borderline boards reliable. It can be overridden with temp_soft_limit=70 to get back to previous behaviour.
  2. fixes for DialogBusy
Build Details:
  1. Firmware (Jun 1):
    • firmware: sdram: Reduce address skew from -10 to -5
    • firmware: platform: Avoid improving the schmoo on Pi3+
    • firmware: platform: Latest AVS rules
    • firmware: sdram: Increase read/write latency for higher sdram frequencies
    • firmware: power: Add boot-time 3b+ PMIC register logging
    • firmware: power: Continue to probe PMIC after error
  2. XBMC:
    • [videoplayer][pvr] Fix crash when copying language codes. (PR:13960, 1 commit, 2 files changed)
    • fix issues related to DialogBusy (PR:13954, 6 commits, 18 files changed)
    • [guiinfo] Fix LISTITEM_RATING parameter handling. (PR:13963, 1 commit, 1 file changed)
    • add GUIDialogNoCancel - work around (PR:13958, 1 commit, 6 files changed)
  3. inputstream.adaptive:
    • [DASH] Don't update initial base_time / decrease base_time to reflect PTO's (babcca4)
  4. Additional commits/pull requests/changes not yet merged upstream:
    • Updated: [env] PR:2731 (perma): enable LTO only for selected packages
    • Added: [env] PR:2742 (perma): scripts/image: add DISTRO_AUTHOR support
    • Updated: [pkg] PR:100 (perma): stats: Replace CPU 32/64 bit flag with GPU enumeration (service.libreelec.settings)
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.
@PhilE
Quote:@aleksobs I'm suspicious about one of the firmware commits - the oldest build not including it is #0511 (https://forum.kodi.tv/showthread.php?tid...pid2734288) and the first with it is #0513 (sic) (https://forum.kodi.tv/showthread.php?tid...pid2734758).

I would be grateful if you could try both builds to see what happens to the USB ports at shutdown and report back.
I tested it on Raspberry PI3 b+. Disabling USB ports in these firmwares (#0513, #0511) at shutdown works correctly.
What exactly is a “borderline” RPi3+ board?
I read this thread daily ( or more), and have a issue someone might have come across

Clean install of Libreelec 8.2.5 Pi2 ( for a new Pi 3B+).
Set up basics, ssh, host name.
Then placed new Milhouse 1st June 2018 rpi2 tar into update folder.
Reboot, and kodi updated successfully.

But, I can not install any add-ons. Every one fails with dependency failed. Does not matter if its a skin, HD Trailer addon, or Netflix (which is what I am after)
Rolled backwards a couple of Milhouse versions, but issue still exists.

So, placed LibreElec 8.2.5 into update folder, and rebooted.
Ta da, can install add-ons perfectly.
Update to #0601 Milhouse, and nope, fails any add-on with depencencys.

Oh, and on start of Milhouse #0601 I see a message remote communication server failed to start, but not on 8.2.5

I know, no log - didn't happen. Just damn tired right now, and thought someone might have an idea what the heck is going on with my system.

I am stumped.
Media Companion Dev.
Media Companion - Kodi / XBMC - Media Companion
  • 1
  • 371
  • 372
  • 373(current)
  • 374
  • 375
  • 495

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