If/when Kodi supports multi-threaded SW decoding .. LE will support multi-threaded SW decoding. Nag upstream.
Posts by chewitt
-
-
Your non-debug Kodi log doesn't show much, but since the media is 2160p ~ if it's an HDR file Kodi does not currently support HDR so the colours will appear muted and washed out. Solution is to see if the original disc has a non-HDR version on the disk and re-rip.
-
I've asked the connman devs for a version bump. Once that's released and tested in Milhouse nightlies I'll resubmit a PR. Now the kernel driver has gone upstream (for Linux 5.6) the packaging is a little easier.
-
I made the decision to stop patching audio card names in the kernel so we hoard fewer patches. This means the AMLGX and AMLG12 card names will be replaced with more random names (whatever is in the device-tree file). Anyway.. I'm still in the middle of fiddling with audio things in the Linux 5.5 kernel so some things work, some don't work. I'll have a look at VIM3 in the next couple of days..
-
"curl icanhazip.com" usually works .. "curl ipinfo.io" also works for me
-
If you can tell us what the firmware name is? .. we can investigate why/where it went missing.
-
"systemctl status kodi.service" ???
-
sinisab89 I binned your last two posts because:
a) If you want to keep discussing CE please use their forum.
b) Users of piracy add-ons like Elementum will not recieve support in this forum.
-
^ edit "PreferredTechnologies = ethernet,wifi,cellular" to be "PreferredTechnologies = wifi,ethernet,cellular" and save/reboot. This ensures connman will allow a persistent default route over WiFi, else when you connect Ethernet connman prefers it and overwrites default routes. You can also use the console "connmanctl" utility over SSH to set the Ethernet interface properties (static address, etc.) but I suspect the GUi will behave once you've changed the technology preference.
-
"If it works, don't fix it"
-
-
Is the content you're playing 4k60? .. if not (and most "not a test file" 4k content in ciruclation is not) you can remove hdmi_enable_4k=1 and the Pi will still support up to 4k30 and will probably run better.
-
I'd guesstimate 50% of the Kodi codebase is equally unmaintained so it's no big deal. The code might be broken if you attempt to use colour management, but as long it doesn't actually cause problems with other areas of Kodi function it's harmless to leave broken, and eventually someone will spot the issue(s) and fix them. I'm on the heretical non-coding side of Team Kodi though so my views don't always count for much
-
-
Not possible because some of the changes necessary for GBM/V4L2 stateless decoder support (matched to the stateless decoder in the newer kernel used in master branch images) do not exist in Kodi v18, or will be mismateched.
-
You'll probably find the vendor u-boot forces the partitions to a read-only state so the pre-mount fsck our init script fails and we abort. You can probably fiddle your way around that with a custom image (that changes init) or custom autoscripts. You'll need to hook a UART cable to the board and see if you can interrupt u-boot to see/dump the environment (which contains all the boot config and scripts) to figure out what's being done and how to work with or around them. The challenge with older boards is that u-boot is often home-grown and quite restrictive and there's less consistency among devices. In later generations most vendors typically follow the prescribed config from Amlogic which despite some fugly hackery is reasonably simple and open to work with.
-
If you want support for Android OS things .. you are in the wrong forum.
-
You would need to recompile the LE distro image with the required kernel config options needed for IPSeC support and the connman build options needed for userspace configuration of IPSeC tunnels via connman vpn plugins (have a look at our past support for PPTP for ideas). There are no HOWTO guides for this and IPSeC is not something we're interested in supporting in our default images so you will need to take the initiative.