So does it work now that you fixed the path?
if not can you post the output of:
Code
systemctl status kodi-autostart.servicePosts by lrusak
-
-
You need to be more specific about what hardware you are using. Some hardware doesn't expose using these buses when using Linux
-
the path doesn't exist /.config/setAVR.py
you need to use /storage/.config/setAVR.py
-
no, it's more along the lines of Building (Basics) - LibreELEC.wiki
-
Once you can play everything at 4k60, the best platform then becomes the one which is most power efficient. IMHO.
the Intel NUC7CJYH was the perfect platform IMO as it can do 4k60 with native HDMI 2.0 and it has a TDP of 10w.
-
Current work-in-progress HDR code from lrusak's git repo (which I use for my LE builds) does not work on AMD. No idea when or if it will ever work.
But the biggest concern should be AMD's linux GPU driver quality, which is kinda crap. I encountered some nasty issues when testing LE on Athlon 200GE APU with Vega graphics.
The audio passthrough issues on Intel are nothing compared to general crappiness of AMD drivers.
You are using the wrong branch
I've used HDR on my AMD vega-m. It's very much WIP though. AMD drivers also don't expose the colorimetry property yet so there is no way to flag bt2020 to the monitor (this is apparently going to be implemented this year though).Also, the AMD drivers (IMO) are some of the best.
-
I can't set the sampling rate or I don't know how to do it.
After setting the output to "fixed" scroll down to the new option "limit sampling rate"
-
Did you also set the sampling rate to 44.1?
Post a debug log
-
you would have to do the work yourself to cross compile LibreELEC to inlude the driver. You can't simply "install" the driver into LibreELEC.
-
The boot problem is that the boot partition for LibreELEC isn't found. This could be because the device isn't recognized or that the uuid changed from the original install, you can verify by comparing the uuid from blkid of the device you want to boot to the uuid listed in cmdline.txt
-
you can set the sampling rate to fixed in the kodi audio settings.
-
You are likely on your own with this device. Amlogic S905 with some random dtb. You will likely break your install if you try to update.
-
It's already there -> EDID - LibreELEC.wiki
-
Update and release file is working for me. Thanks lrusak ! Since you updated the release-scripts: is generating the releases.json already integrated in the CI (or however generating/upload of nightly builds work...)?
unfortunately it's not hooked into CI yet. We are in a bit of a maintenance update right now so jenkins is being reworked a bit. It would be ideal though to run this script from CI. We would also like to increase our nightly storage so we can have a few images listed.
-
You'll have to add a custom channel for now but please give this a test.
-
Seems I'm still the most knowledgeable man with i.MX6Q U-Boot
Want a cookie?
Why haven't you PR'd your changes yet?
-
I guess we can boot all iMX6 targets with one image using boot.scr
I tried this with Wandboard B1 and C1 and it works.
The script I used:
Codesetenv image "/KERNEL" setenv bootargs "boot=UUID=2511-1511 disk=UUID=3a00fe1a-8c24-42fd-83ae-69c4a2043aa0 quiet console=ttymxc0,115200" load ${devtype} ${devnum}:${distro_bootpart} ${kernel_addr_r} ${image} load ${devtype} ${devnum}:${distro_bootpart} ${fdt_addr_r} ${fdtfile} bootz ${kernel_addr_r} - ${fdt_addr_r}No one wants to use boot.scr files. If it works for you, awesome, but it doesn't work for the LibreELEC project as a whole.
-
Users don't need to set any dtb name because all magic is happening automatically in u-boot. U-boot for solidrun check the SoC type and sets one part of the dtb (imx6dl or imx6q). Then it also checks the SoM type (cubox, hummingboard, hummingboard2) and at the end also SoM revision (v15 or nothing). So same image runs on every device from solidrun without knowing what type it is and without setting dtb name. Same thing is happening on u-boot for Wandboard and Udoo. But there is probably just setting SoC type (at least this was true for Udoo when I add support for it).
But maybe mainline u-boot remove or broke all those things
So lrusak: you still think it doesn't matter how u-boot works?
I'm aware of this logic. The problem is that this is only the case for a few platforms within iMX6 u-boot. Other platforms don't operate like this and I would rather leave it generic than change it because of some boards on one platform. So the user has to flash the correct image the first time they install it. It's 50/50 anyways.
We also use extlinux and write the dtb filename to the extlinux.conf file at build time. This doesn't support specifying more than one dtb.
