• 1
  • 57
  • 58
  • 59(current)
  • 60
  • 61
  • 86
v19 LibreELEC Testbuilds for RaspberryPi (Kodi 19.0)
Using the "old" #0309 firmware (fixup.dat, start.elf, bootcode.bin) with #0310 (kernel 5.4.24) and the WiFi firmware is loading reliably in the modified #0310, so this does seem to be an issue with the new firmware, and not the new kernel.

Just to be absolutely sure, I copied the "new" firmware from #0310 to #0309 and WiFi firmware loading became unreliable in the modified #0309, so the WiFi firmware loading problem transfers with the "new" firmware.
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.
I rolled back to #309 about a week ago, my RP3 was freezing with 310 forward. I didn't save any crash logs, but freezing was almost immediate after trying to play a video.
@J_E_F_F were you overclocked in any way?
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.
New LibreELEC.tv Matrix build #0322: RPi / RPi2
(Supercedes previous build)

SHA256 Checksum: 93d60560b7ec297119bb0f73287f1ded145c0828279b504b22021caf03b68b61 (RPi)
SHA256 Checksum: a799b74fcfd1c60840e124f418c6ec995940c81be1aecdb7bb17a9d2df6aa452 (RPi2)

text:
# uname -a
Linux rpi512 5.4.24 #1 Sun Mar 22 21:34:26 GMT 2020 armv6l GNU/Linux

# vcgencmd version
Mar 10 2020 18:38:51
Copyright © 2012 Broadcom
version 74d7f53b091e465285f38fb96896a8fc328e4c47 (clean) (release) (raspberrypi_full_legacy)

# lsb_release
LibreELEC (Milhouse): devel-20200322213345-#0322-gf917ae0 [Build #0322]

# Kodi version
Kodi (19.0-ALPHA1 Git:9541669). Platform: Linux ARM 32-bit

Based on tip of LibreELEC.tv master (f917ae0, changelog) and tip of XBMC master (9541669, changelog) with the following modifications: Build Highlights:
  1. [PVR] add watched count to grouped recordings list
Build Details:
  1. LibreELEC.tv:
    • libprojectM: update to 3.1.2 (PR:4273, 1 commit, 2 files changed)
    • linux: fix wireguard build on iMX6 image (PR:4272, 1 commit, 1 file changed)
  2. XBMC:
    • [PVR] add watched count to grouped recordings list (PR:17516, 1 commit, 1 file changed)
    • [json-rpc] favourites - add support for androidapp (PR:17511, 1 commit, 4 files changed)
    • [Android] pause audio playback when headphone is disconnected (PR:17030, 1 commit, 1 file changed)
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.
(2020-03-22, 20:28)Milhouse Wrote: @J_E_F_F were you overclocked in any way?

Yes, and I've been meaning to ask if that was a good thing these days, I haven't messed with it in a year or more, maybe even 2 years and a lot has changed with the code since then.
This is what I have:
Code:
[pi3]
# arm_freq=1300
core_freq=500
gpu_freq=500
over_voltage=2
dtparam=sd_overclock=83
sdram_freq=580
over_voltage_sdram=5
sdram_schmoo=0x02000020

What is the norm these days?
(2020-03-23, 04:51)J_E_F_F Wrote:
(2020-03-22, 20:28)Milhouse Wrote: @J_E_F_F were you overclocked in any way?

Yes, and I've been meaning to ask if that was a good thing these days, I haven't messed with it in a year or more, maybe even 2 years and a lot has changed with the code since then.
This is what I have:
Code:
[pi3]
# arm_freq=1300
core_freq=500
gpu_freq=500
over_voltage=2
dtparam=sd_overclock=83
sdram_freq=580
over_voltage_sdram=5
sdram_schmoo=0x02000020

What is the norm these days? 
around the same build, I had issues just getting my pi3b to boot.  Commenting out all overclocking fixed my issue and everything has been smooth since.  I would try that first.
(2020-03-23, 04:51)J_E_F_F Wrote: Yes, and I've been meaning to ask if that was a good thing these days

Personally, I've disabled all overclocking. I don't think it's a very good idea when testing new firmwares as it's one more issue and overclocking - while supported - isn't guaranteed, so an overclock that worked with old firmware may not work with new firmware (and such a failure wouldn't necessarily be classed as a problem, because it's not guaranteed etc.).

When I've had weird or one-off crashes in the past, I'm pretty sure it's always been down to an overclock that either wasn't 100% stable (as I had thought) or has become less stable due to updated firmware (which is stable at stock clocks).

So yes, if possible, try testing without overclocks. Certainly avoid "extreme" overclocks.

The only "overclock" I use on RPi3+ these days is dtoverlay=sdtweak,overclock_50=100

Perhaps the overclock issues will be looked into once the "new" firmware is fully baked with stock clocks (and as time permits). The wifi firmware loading issue is a regression that may be due to clock/PLL issues, as the following fixed clocks appear to be working fine (ie. wifi firmware is loading):
text:

core_freq=250
core_freq_min=250
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.
New LibreELEC.tv Matrix build #0323: RPi / RPi2
(Supercedes previous build)

SHA256 Checksum: cbbfaeafffc35e0596de47f923e5b343972573bada53cd1299f5974da9113218 (RPi)
SHA256 Checksum: 6ebf3c74ff760d81a0fd3fb5161ce874bfde3f4c0e0ff660308f0addd876d43a (RPi2)

text:
# uname -a
Linux rpi512 5.4.27 #1 Mon Mar 23 21:04:30 GMT 2020 armv6l GNU/Linux

# vcgencmd version
Mar 10 2020 18:38:51
Copyright © 2012 Broadcom
version 74d7f53b091e465285f38fb96896a8fc328e4c47 (clean) (release) (raspberrypi_full_legacy)

# lsb_release
LibreELEC (Milhouse): devel-20200323210349-#0323-gaeb6e84 [Build #0323]

# Kodi version
Kodi (19.0-ALPHA1 Git:92d0e06). Platform: Linux ARM 32-bit

Based on tip of LibreELEC.tv master (aeb6e84, changelog) and tip of XBMC master (92d0e06, changelog) with the following modifications: Build Highlights:
  1. New 5.4.27 kernel
  2. Python API cleanup (current LE Settings add-on is partially broken, will fix tonight)
Build Details:
  1. LibreELEC.tv:
    • bluez: update to bluez-5.54 (PR:4266, 1 commit, 1 file changed)
    • mesa: update to mesa-20.0.2 (PR:4269, 1 commit, 1 file changed)
  2. XBMC:
    • CUDMABufferObject: add new class to abstract memfd/udmabuf buffers (PR:17523, 2 commits, 5 files changed)
    • [GBM][Wayland] share EGL base class (PR:17517, 3 commits, 7 files changed)
    • [RetroPlayer] rename GBM related buffers/pools/renderers to DMA (PR:17524, 2 commits, 10 files changed)
    • CDMAHeapBufferObject: add new class to abstract new dma-heap buffers (PR:17532, 2 commits, 5 files changed)
    • Python API cleanup (PR:17456, 6 commits, 19 files changed)
    • [FIX] Chapter selection in UHD BD and BD (PR:17210, 1 commit, 1 file changed)
    • [python] add custom button to yesno dialog (PR:17494, 1 commit, 2 files changed)
    • [PVR] CPVREpgTagsContainer::GetTimeline : Fix edge case (PR:17545, 1 commit, 1 file changed)
    • Favourites Dialog - fix crash (PR:17528, 1 commit, 1 file changed)
    • [settings/lib] support static <enable> tag for <setting> definitions (PR:17546, 1 commit, 2 files changed)
  3. pvr.argustv:
    • [Matrix] use AddonBase.h, LICENSE add, cleanups (PR:99, 6 commits, 9 files changed)
  4. pvr.demo:
    • [Matrix] few cleanups and LICENSE.md add (PR:76, 4 commits, 9 files changed)
  5. pvr.hdhomerun:
    • pvr.hdhomerun updates (PR:93, 1 commit, 4 files changed)
  6. pvr.vuplus:
    • [Matrix] use AddonBase.h, LICENSE add, copyright year increase (PR:277, 8 commits, 81 files changed)
  7. Additional commits/pull requests/changes not yet merged upstream:
    • Updated: [env] PR:4237 (perma): linux (Generic/Allwinner): update to linux-5.5.13
    • Updated: [env] PR:4243 (perma): linux (RPi): update to linux-5.4.28
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.
I'm struggling with a problem. Sad
I was on Milhouse Kodi 18 (April 2019) since today. But the last weeks I got more and more problems with some xbmc.python dependency. I googled the error message and the tip was to update/upgrade my Kodi version.
After I tried the Milhouse alpha from yesterday and had still the same problems with it (and the Amazon and Netflix addons refused to install), I installed the official LibreElec 9.2.1, but its running not very well on my RPi 3, had a lot of lags and things like that. Also my Kore app on my phone seems to have problems with it (does not automatically show the text input and searches on youtube went suddenly empty). Then I tried the Milhouse alpha again: Netflix, Youtube and Amazon VOD refused to install, Kore does also behave erratic and this time the Wi-Fi was gone ...
I just want to have a stable system for Youtube, Netflix and Amazon VOD without that xbmc.python depenency problem.
Has anyone a solution for me?
OK, as above I disabled all overclocking on both my RP3s and updated from #0309 to #0323.
One RP3 boots just fine, the other boots but has no wifi connection.

If I put back the start.elf and fixup.dat from #309 it boots and wifi works with the rest of #0323

Again 2 RP3s, one works directly from #0323, and the other requires start.elf and fixup.dat from #309. Very weird.
(2020-03-24, 00:37)Ich-bin-Knuffi Wrote: I just want to have a stable system for Youtube, Netflix and Amazon VOD without that xbmc.python depenency problem.
Has anyone a solution for me?

Yes, there's currently quite a few problems with Python and Kodi 19 - it probably wasn't a good idea to test Kodi 19 at this time as it may now have disabled a number of add-ons and/or add-on dependencies that may now impact your LibreELEC 9.2.1 build (the addons/add-on dependencies may remain disabled in your Addons27.db etc.).

I would suggest a clean install of LibreELEC 9.2.1 if you want a stable experience, and avoid Kodi 19 for the time being.
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.
(2020-03-24, 05:32)J_E_F_F Wrote: OK, as above I disabled all overclocking on both my RP3s and updated from #0309 to #0323.
One RP3 boots just fine, the other boots but has no wifi connection.

If I put back the start.elf and fixup.dat from #309 it boots and wifi works with the rest of #0323

Again 2 RP3s, one works directly from #0323, and the other requires start.elf and fixup.dat from #309. Very weird.

Are both RPi3 using WiFi? Try rebooting the "working" RPi3 a few times, and see if it successfully loads the WiFi firmware every time (if it doesn't, it won't have working WiFi etc.).

The WiFi firmware loading issue seems to be present most of the time (at least on my RPi3+) but very occasionally the WiFi firmware will load successfully - it's a clocking issue so success/failure may depend on how heavily loaded the CPU is while booting, and which way the wind is blowing.
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.
(2020-03-24, 06:48)Milhouse Wrote: Are both RPi3 using WiFi? Try rebooting the "working" RPi3 a few times, and see if it successfully loads the WiFi firmware every time (if it doesn't, it won't have working WiFi etc.).

Yes, both using WiFi and accessing the same remote win10 MySql DB and file shares.

I rebooted both 6 times, one successfully all 6 times and the other failed WiFi all 6 times. With the exception of the name, they are set up identically, though the failing one is in a Flirc case, the working one is not in a case.

I also took the MicroSD card from the working RP3 and tried it in the non-working one, it failed both times I tried it. Weird!
Here's something else different between the 2 RP3s.
The working one uses a slightly lower CPU voltage, runs cooler, and when sitting idle properly has the h264 clock at zero

Image

The failing one at idle runs warmer with a slightly higher voltage, and has the h264 clock enabled

Image
(2020-03-24, 16:03)J_E_F_F Wrote:
(2020-03-24, 06:48)Milhouse Wrote: Are both RPi3 using WiFi? Try rebooting the "working" RPi3 a few times, and see if it successfully loads the WiFi firmware every time (if it doesn't, it won't have working WiFi etc.).

Yes, both using WiFi and accessing the same remote win10 MySql DB and file shares.

I rebooted both 6 times, one successfully all 6 times and the other failed WiFi all 6 times. With the exception of the name, they are set up identically, though the failing one is in a Flirc case, the working one is not in a case.

I also took the MicroSD card from the working RP3 and tried it in the non-working one, it failed both times I tried it. Weird!

Thanks. It's possible the success/failure is based on a number of variables that may vary slightly from SoC to SoC (silicon lottery). It's an issue that is being looked into, so once we have a fix you may be a good Guinea Pig. Smile

(2020-03-24, 16:37)J_E_F_F Wrote: Here's something else different between the 2 RP3s.

It looks like the "new" firmware is running cooler (lower voltage)? I suspect there's still some tuning of the PLLs necessary which may explain why some boards are working and some failing.

The H264 block being left enabled shouldn't be anything to worry about, it happens from time to time - I suppose ideally it would always be off when not required, as that might save some volts/heat/etc.

Side note: If you use the "e" option with bcmstat.sh, you should be able to view the active core voltage which should change with frequency:

Image
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.
  • 1
  • 57
  • 58
  • 59(current)
  • 60
  • 61
  • 86

Logout Mark Read Team Forum Stats Members Help
LibreELEC Testbuilds for RaspberryPi (Kodi 19.0)8