video=HDMI-A-1:1920x1080M@60Force 1080p output by adding that ^ to kernel boot params in cmdline.txt (append to the same line NOT on a separate line). I'd also stop Kodi and rename /storage/.kodi/userdata/guisettings.xml then restart to reset GUI config to defaults.
Generic = GBM only (not Wayland) supporting only Intel/AMD chips
Generic Legacy = Xorg supporting Intel/AMD and nVidia chips
xrandr is (as the name suggests) an Xorg thing so doesn't exist in the normal image. If output is on the wrong screen you'll have to add kernel boot params to disable output on the laptop screen (allowing DP to be auto-selected). If there's no output at all you'll need to share system and Kodi logs for further investigation. Or just stick with the Legacy image (for as long as we create it).
Have a read here: https://www.tomshardware.com/how-to/control…o-with-python-3
The article was written for RPi5 but the changes apply to all Pi boards running the latest RPiOS release. The kernel bump to Linux 6.6 is not responsible but other changes that were packaged at/around the same time result in changes.
Neither log is a debug log so there's not much to investigate. The only errors that stand out are from things like Tvheadend server not reachable (which will be unrelated).
HDR support has no dependencies on resolution, but does require the TV/monitor to advertise support for HDR colorimetry. Please run "pastekodi" and share the URL so we can see the EDID output in kodi.log.
systemctl stop kodi
mv /storage/.kodi/userdata/guisettings.xml /storage/.kodi/userdata/guisettings.old
systemctl start kodi^ that will restart Kodi with clean settings config .. to test whether discarding or resetting something will solve the issue? - and it's simple to revert back to the previous config if not.
I have a few Apple airport express devices that I use as WiFi > Ethernet bridges to make board testing easier. They're not the fastest things for streaming (but that's true of most WiFi things anyway). The last one I bought from eBay(UK) was about £12.
Following the "if it works, don't fix it" principle an RPi4/5 board reusing the same Allo amp board would be a simple refresh. The CPU performance bump from RPi2 > RPi5 will be rather noticeable.
mount -o remount,rw /flash
cp /usr/share/bootloader/meson-gxbb-odroidc2-hifishield.dtb /flash/
sed -i 's/meson-gxbb-odroidc2/meson-gxbb-odroidc2-hifishield/g' /flash/extlinux/extlinux.conf
mount -o remount,ro /flash
rebooot^ repeat, we moved extlinux to a directory at some point.
If you label the partiton that it being mounted udevil will mount it as /var/media/<label>
How you label depends on the filesystem type, e.g. ext4 partitions are done using e2label.
Would you like to install the needed tools? (y/n)yes _emanuel_ You probably need to type 'y' not 'yes' so it didn't install anything (and so it's still missing and the build fails).
it seems impossible to unmount the /flash device because it is busy. Can it be the source of my problem ?
Our shutdown script waits for a while for running processes to exit gracefully, but there's a timer running and if the timeout value is reached it kills them and this ensures nothing is busy and the filesystem can be unmounted. It's more likely to be the BIOS on the device not responding properly to a power-state change; assuming it's an x86_64 device. What hardware is this?
"No WiFi" requires an explanation of what chip is inside the box before anyone can comment.
Nope, official updates are normally done using .tar files as those are faster to unpack/update from. The .img.gz also works but needs an extra step. Both have identical KERNEL/SYSTEM and .dtb files inside.
I did a little research on the HK forum and we need to construct a new device-tree overlay that adds nodes for the pcm5102 chip and audio card routing. Update to this file (again, it's been updated):
https://chewitt.libreelec.tv/testing/LibreELEC-AMLGX.aarch64-11.80.0.tar
Then run the following from the SSH console:
mount -o remount,rw /flash
cp /usr/share/bootloader/meson-gxbb-odroidc2-hifishield.dtb /flash/
sed -i 's/meson-gxbb-odroidc2/meson-gxbb-odroidc2-hifishield/g' /flash/extlinux.conf
mount -o remount,ro /flash
reboootThis should switch u-boot over to the hifishield device-tree file, and then we discover how accurate my blind guesswork was?
Please share URLs from "dmesg | paste" and "aplay -l | paste" and "aplay -L | paste" so we can see if anything happened.
To be clear, I'm not expecting audio output in Kodi yet, as I suspect audio mixer routing changes are required too.
The output of "pastekodi" includes the system log (dmesg) which is where we can see the drivers probe and load firmware (or not) which is more useful. Kodi debug logs don't contain any of that.
It's beest to report that kind of problem to the add-on author in the Kodi forums. It's not something we're responsible for (and thus not our area of expertise).
I've added the driver to this image: https://chewitt.libreelec.tv/testing/LibreE…h64-11.80.0.tar
I suspect the driver is only part of the puzzle though. I believe there are device-tree overlay and perhaps mixer changes too. One step at a time though.
EDIT: forgot to sync the image .. Give it 10 mins before downloading.
Martin threatening to do kernel work sounds awesome! If there is stuff to test I am happy to do it.
Martin pushed an updated kernel branch: https://github.com/xdarklight/lin…n-6.7-20231203/ - I'm not seeing anything obviously new in terms of commits, but it's an excuse to do a rebase for AMLGX sometime soon.
