Posts by chewitt

Use "chown" to change ownership and "chmod" to change permissions .. assuming the disk is EXT4 formatted and supports Linux permissions.

The other add-on hints the user is in Russia (or a Russian speaking country) which makes the use of legal IPTV services rather unlikely.

You can try some of the S805 community images in the forum. It's not something we have any official support for.

Start with a clean system (remove the pirate IPTV feed and torrent streaming crap). Problem solved?

#5651 (add QDMC decoder) – FFmpeg

git.videolan.org Git - ffmpeg.git/commitdiff

^ ffmpeg appears to support the format, so you should post an issue on the Kodi GitHub tracker along with a debug log demonstrating the problem and a sample of the video so that one of the developers can reproduce the issue.

Set the interface to 1080p and check cables.

Unlike S905+ where there's a semi-official generic image, there's nothing for Meson 8 hardware. So you need to experiment with the available builds and see what works.

Read the screen. What does it say about submitting crash logs? .. else we can only guess at the reasons (add-on issues are often the cause).

It's possible that the refresh rate and colour depth being used by the splash disagrees with your TV and so it shows a black screen. As long as Kodi starts okay there's nothing to really care about.

Quote from spaceship9876

S905X can't output 10bit video to tvs?

GXBB/GXL can read 10-bit and output 10-bit, but there's an intermediate stage that converts to 8-bit for processing. GXM is fully 10-bit.

Yes this works (see the post from awiouy in response earlier where he confirms) but as you correctly suppose, you cannot have Kodi active and the other distro active at the same time else both fight over the same hardware resources. This is also the case with the current Chrome addon for x86/64 (X11) where Kodi needs to be stopped while it's active - and it's one of several reasons why we regard the current "solution" as a bit of a hack and that something fully integrated into Kodi is real way forwards. However the exploratory work that's already been done in this area by Kodi developers has also shown that it's not a trivial capability to add, so while you are correct to be non-defeatist (it's not impossible and someone just has to do it) we're also correct to be realistic about the likelihood of it being done anytime soon (in the last 10-year period, nobody didi it).

Casting would also be nice and a solution for many users, but that also requires Kodi support and the developers are really not fans for proprietary crap (a lesson learned the hard way) so the reality of there being multiple "standards" for casing depending on macOS/Win/Linux/iOS/Android means it's also a reverse-engineering/bad-code and political issue. So native casing isn't likely to be a fruitful way forwards either.

So on this specific topic "get a chromecast" or dual-boot with Raspbian/Armbian/etc. are "sucky but sensible" options and IMHO chromecast would be the more practical to live with.

I don't see Rockchip as particularly better than Amlogic when it comes to upstream/mainline development. Both vendors are mainly still focussed on legacy codebases (4.4 for RK and 4.9 for AML) and despite RK having a GitHub presence both vendors work mostly in private repos. And since the focus of all new code is (or should be) the upstream kernel both vendors have similarly sized/active teams of independent kernel maintainers (the kernel prefers non-employees). Both vendor mainline efforts are missing stuff and the only real-world difference is in what the missing bits are. Right now (from a mainline readiness LE oriented viewpoint) Amlogic is actually the more usable one due to RK missing the VPU.

Most of the missing Amlogic components (10bit output, framebuffer compression methods and audio) either have funded work packages lined up or a known/probable contributor who's expressed interest in working on it. The one item that has no "owner" yet is the hardware deinterlace capability. Support for ge2d exists in the legacy kernel but like many things in the BSP kernel, the existing code is poorly structured and over-complex (a house that has been extended and remodelled over time) and it won't transplant directly to V4L2. So it's necessary to reimplement and not simply forward-port the existing code. Could that be something of interest?

buzzmarshall autoscript.sh runs very early in the boot process and the network stack is almost certainly not up/ready at that point.

cpumac: add cpumac package · chewitt/LibreELEC.tv@e011b00 · GitHub is how I solve this in my test images.

It means right now we are focussed on core video/audio support more than figuring out some of the packaging mess required for WiFi/BT firmware and nvram files. It's something we need to align for Allwinner, Amlogic and Rockchip.

RockPro64 is a popular RK3399 board among a variety of RK developers.

LE has zero interest in supporting X11 on ARM hardware. In fact we're going to remove X11 from x86/64 hardware in the future too (which kills the current browser support there). So the remaining approach/solution which also works today is to run a browser like Chrome via docker. In essence you're going to run some kind of desktop distro (with X11 and the stuff it depends upon) in a container in the background. That probably doesn't do any favours for performance, but you get a working browser.

Before you ask, there is no nicely typed up guide on how to run a browser in a container. It's been done before though.

RK has a native 10-bit pipeline, same as S912.

Kodi supports Wayland as the long-term successor to X11 (a successful Kodi GSOC project from 2017) and there are several desktop oriented distro's that support Wayland and people who actively tinker with that combo. LE has no need or plan to use Wayland though. Maybe the lack of browser in Kodi (e.g. via CEF) will be resolved.. nobody knows.

u-boot stores the MAC in efuse and the kernel reads the values back from efuse