Posts by chewitt

LEIoT:~ # docker version
Client:
 Version:           26.1.3
 API version:       1.45
 Go version:        go1.22.3
 Git commit:        b72abbb6f0351eb22e5c7bdbba9112fef6b41429
 Built:             Fri Jun  7 14:43:10 UTC 2024
 OS/Arch:           linux/amd64
 Context:           default

Server:
 Engine:
  Version:          library-import
  API version:      1.45 (minimum version 1.24)
  Go version:       go1.22.3
  Git commit:       library-import
  Built:            library-import
  OS/Arch:          linux/amd64
  Experimental:     false
 containerd:
  Version:          1.7.17
  GitCommit:        3a4de459a68952ffb703bbe7f2290861a75b6b67
 runc:
  Version:          1.1.12
  GitCommit:        51d5e94601ceffbbd85688df1c928ecccbfa4685
 docker-init:
  Version:          0.19.0
  GitCommit:

Odd .. this is what I see ^ albeit this is with a custom image where Docker is embedded (not installed as an add-on as there's no Kodi in the image) but I'd expect the results to be the same (as same build system).

Nothing changed and "getedid create" still works the same as the last 5+ years. RPi boards store boot params in /flash/cmdline.txt.

I've been able to replicate the issue with my C2 board. It boots KERNEL but then fails to load SYSTEM with the famous "Error in mount_flash: mount_common: Could not mount LABEL=LIBREELEC" and eventually the UART console fails to the initramfs shell where I've been able to get some logs which show an error with the ddr-50 mode:

Combining the tf_io GPIO_OPEN_DRAIN patch and removing sd-uhs-ddr50, the card I'm using now installs/boots/reboots fine.

Please retest with: https://chewitt.libreelec.tv/testing/LibreE…droid-c2.img.gz

Maybe some info in here: https://github.com/LibreELEC/documentation/pull/18/files

Feedback on the content appreciated. If it 'works' I'll merge it and clean-up the wording a little. I've never network booted any of my devices (and not a trick I need to learn) and nobody else has ever confirmed the text.

Just compress the log in a zip file and upload it somewhere

Feb 27 18:26:11.509638 INTSVC-STREAMPI connmand[575]: Skipping server 172.21.21.254 KoD code RATE
..
Feb 27 18:26:25.768188 INTSVC-STREAMPI connmand[575]: Skipping server 172.21.21.254 KoD code RATE
..
Feb 27 18:26:39.762246 INTSVC-STREAMPI connmand[575]: Skipping server 172.21.21.254 KoD code RATE
..
Feb 27 18:27:01.976455 INTSVC-STREAMPI connmand[575]: ntp: adjust (jump): +8815445.461668 sec
Jun 08 20:11:07.439421 INTSVC-STREAMPI connmand[575]: eth0 {add} route 82.165.8.211 gw 172.21.21.254 scope 0 <UNIVERSE>
..
Jun 08 20:11:07.499950 INTSVC-STREAMPI connmand[575]: Skipping server 172.21.21.254 KoD code RATE
..
Jun 08 20:11:22.227952 INTSVC-STREAMPI connmand[575]: Skipping server 172.21.21.254 KoD code RATE
Jun 08 20:11:36.227660 INTSVC-STREAMPI connmand[575]: Skipping server 172.21.21.254 KoD code RATE
Jun 08 20:12:05.538565 INTSVC-STREAMPI crond[438]: time disparity of 146925 minutes detected

(re)configure your NTP server to stop sending Kiss of Death (KoD) responses when we attempt to sync against it and we'll manage to reset the time much earlier in the boot sequence. Or just leave NTP unconfigured and we'll default to pool.ntp.org servers which normally work fine for people.

As nice as those cases are, we've seen a lot of silly problems with them. YMMV.

It was located in /storage/.config/hwdb.d but I did some searching on the internet among other distros and consolidated all the ok button hwdb entries I could find into a single file; including the OSMC remote changes. Once that was merged the 99-osmcef.hwdb file wasn't needed anymore. You can still create your own files there.

Official:Forum rules/Banned add-ons - Official Kodi Wiki

No support for you in this forum.

HDMI was submitted last week. That opens up the option for LE to create an image that software decodes all media, which will be quite usable as RK3588 has a strong CPU. Otherwise we now need to wait for codecs. That's always the tricky bit that takes ages for developers to get done (and get right). Meanwhile .. time passes.

Kodi calls an embedded lib that can be influenced by the Kodi smb.conf config, but it is not using the smbclient binary (which uses a separate host smb.conf) so while it may work from the console client, you are not testing the same code path.

Path sub works becaus the local console client works, but again ^ it's not proving the same thing.

ilovebytes someone replied to special post in the HK forums with a link to this:

Odroid C2 | Does not boot on reboot without power cycling · Issue #5414 · MichaIng/DietPi

DietPi version | G_DIETPI_VERSION_CORE=8 G_DIETPI_VERSION_SUB=1 G_DIETPI_VERSION_RC=2 G_GITBRANCH='master' G_GITOWNER='MichaIng'…

github.com

This image: https://chewitt.libreelec.tv/testing/LibreE…droid-c2.img.gz now contains that change. Please go test and report back.

Not all HDMI ports are equal specification. Some TVs only support specific input on specific connectors. Some support everything on all connectors. Most common on a modern TV is the hardware supporting everything but default software config forcing different specs on different inputs. Deep Colour or similar is normally required for 4K60 and 4:2:2 input.

Remove the EDID forcing because this will override EDID on the HDMI connector and enabling/disabling "Deep Colour" on the port will change the EDID output from the TV on HDMI.

Then configure Deep Colour ON, adjust refresh ON, ensure no 4096 modes and 3840@60/59.94/50/30/29.97/25/24/23.98 are in the list, reboot for clean logs, then share a debug log showing something with HDR content.

special I did some device-tree archaeology on the Linux 3.14.y sources (used in LE 9.x images) and HardKernel 3.16.y sources.

LE sources only describe the basic "highspeed" card mode and max-speed as 100MHz. HK sources support highspeed and UHS 50/104 card modes, but a lower max-speed of 85MHz. The upstream kernel describes highspeed and UHS 12/25/50 (and DDR50 for some reason) but not UHS104, with max-speed set to 100MHz.

The current image here: https://chewitt.libreelec.tv/testing/LibreE…droid-c2.img.gz aligns the upstream kernel controller capabilities and speeds with the HK vendor kernel (remove UHS12/25 and DDR50, add SDR104, reduce the max-speed to 85MHz). Please write to a card (the problem card) and see if that makes any difference?

The reason I was asking about SMBv1 is https://github.com/xbmc/xbmc/pull/25295 .. but that wouldn't be the case. It might be worth seeing if different chunk sizes resolve the issue. This is configurable in Kodi settings now.

Have a look for dtech threads with LE 9.2 images for some devices (no idea about that one). There's nothing newer - there's no real-world mainline kernel support for 8726MX chips.

If the caching defaults don't work with 2.5GB/1GB Ethernet you need to fix your broken network not fiddle with cache settings. I would remove that to reduce the potential scope of the problem.

I used RPi3 in the past but always preferred a NUC or Amlogic box that was faster, albeit the Pi board was always a bit more reliable with media. Then RPi4 came along and moved the goalposts; same reliability but now acceptably fast and with good 4K/HDR support for newer HEVC media that I've ripped. Then RPi5 came along; functionally the same but making the RPi4 feel like some ancient slow thing from a decade ago as it's NUC fast. RK3399 is fairly well supported in the kernel now (much better than Amlogic) and on-paper it has more codecs than RPi4/5 .. but software maturity isn't in the same top-league as RPi4/5.