Posts by chewitt

What happens if you install LE10 (Matrix) then update the system to LE12 (Omega)?

NB: Does the same happen with LE11?

Kodi Omega supports GUI configuration of NFS protocol version (defaults to v4) and chunk size (defaults to 128KB), and similarly the SMB chunk size is exposed (defaults to 128KB). It's possible the defaults are causing issues and you might need to experiment with different values to get things working as before.

I'm going to send a PR to add this patch into LE12 nightlies (and then 12.0.1) and if no issue reports come up I'll send it to the upstream kernel. I'm reasonably confident it doesn't cause issues as it's been included in my Amlogic images for several years already, but those don't have the size of audience that RPi has so a little caution is needed.

The helper handles the sourcing of widevine libs used for playing DRM encrypted media. I'm not sure YouTube offers any widevine encrypted media so it's probably not required, but if you have plans to use Netflix or Amazon add-ons (and others) it's something that you will need. It's harmless to add in all cases.

I read the tea=leaves in my cup this morning but it hasn't helped with diagnosis. Sharing the URL from "journalctl | paste" would be more fruitful. We need to system the system log please.

HarryH here's an RPi4 image with the same patch https://chewitt.libreelec.tv/testing/LibreE…ch64-12.0.0.tar

Edit uEnv.ini to use meson-g12b-gtking.dtb, do not rename the file to dtb.img - the boot process is different to CE and CE dtb files are NOT compatible. More info here (in English): https://wiki.libreelec.tv/hardware/amlogic

It would be useful to see the system (not Kodi) log when the USB device is attached. And yes "it's only a USB stick" but what is the PSU rated for? .. bad behaviour during boot and device attachment is a common symptom of unstable power.

Nothing stands out in the log, although it's not a debug log so it's harder to guess what Kodi internals might be doing. It's normal for things in databases and caches to be reprocessed and validated though, and in the background Kodi downloaded new versions of add-ons too, which included services like Tvheadend. Give it an hour and see if the dust settles.

Changes in https://chewitt.libreelec.tv/testing/LibreE….arm-12.0.0.tar might do the trick then. If yes, I must nag Kwiboo about upstreaming that patch

It can be changed though, fortunately..

Once Kodi figures out how it wants to output it requests alsa channel maps and then walks the list to find a match. List ordering is involved here so _marklam_ please update to https://chewitt.libreelec.tv/testing/LibreE….arm-12.0.0.tar and see if anything changes for you. It's the LE12 release with some personal cosmetic changes and https://github.com/chewitt/linux/…95c6bb50b5431c3 applied to the kernel. I don't think it will make a difference, but you never know.

popcornmix any ideas?

The AVR advertises BL/BR and BLOC/BROC over HDMI. ALSA refers to BLOC/BROC as RLC/RRC but the media being played uses a normal 7.1 layout with SL/SR side speakers which alsa matches to SL/SR using: https://github.com/xbmc/xbmc/blob…A.cpp#L288-L289.

If the widest rear speakers are denoted as BL/BR i'd argue that Kodi is doing the right thing when it sees BL/BR with an exact match and then maps the inner rears as a virtual RC channel resulting in a 6.1 layout. It doesn't make sense to me to use inner-rears as BL/BR and the outer-rears as SL/SR. If that's the result you're looking for; reconfigure the positions in the AVR or rewire the speakers to be SL/BL/BR/SR then the ELD presentation should reflect that and Kodi should give you that.

Generic (GBM) supports HDR, does not support Chrome. Generic-Legacy (X11) does not support HDR, has Chrome. It's possible to install Transmission but we do not provide piracy tools from any of our repos, so figuring that our is on you - and be mindful of our forum rules if you want support.

Buffer settings typically cause more problems than they solve and most tweaking articles are written by people with no clue how the underlying code actually works (and has changed in recent times). In short: if your network works, you have no need to tweak buffer settings. If your network doesn't work, fix your network. NB: Long Ethernet cables might not be desirable for normal use but can help triage the problem, i.e. if the problem goes away on Ethernet, the problem is that WiFi is often rubbish, and the solution is to (again) fix the network.

LE injects/adds some additional bits into the boot flow but if those files are not found the box should default to Android. If you've used "install2internal" then you may have removed/overwritten some of the Android partitions. Amlogic (Android) ".img" files are normally for use with Amlogic Burning Tool and the USB OTG port not the Android on-box/OTA recovery process, so I'd try flashing with that first. Google will find you a few thousand HOWTO articles and the binaries if you're not familiar with it - it's not really an LE topic we handle. Forums like 4pda are probably more helpful.

Starting over should not be needed, but when faced with a weird/old TV that's not playing ball and someone with a much upgraded config (and thus likely hoarding unknown bits of old config) .. a clean install eliminates some guesswork and reduces the number of variables involved.

RPi boots using code (that cannot be changed) in the chip. This boots firmware on the SD card which reads EDID data from HDMI, which boots Linux, which reads EDID data from HDMI, which boots Kodi, which reads EDID data from HDMI.

RPi boots from an SD card. So just use a different card to test with LE12 and then the existing setup isn't touched. You don't need a Linux machine to create a bootable SD card (even lowly Windows can manage it, and we have an app to make it simple).