For what it's worth the old issue of the `current` Nvidia driver in Generic build hanging the machine when entering suspend is also present in Leia v8.95.2 Beta (the workaround of forcing the ancient legacy driver still functions)
I think we will have removed nvidia support from our codebase before the suspend issues (which go back to OE days) will ever be resolved.
Assumptions about availability of Amlogic documentation and how various relationships inter-relate aren't correct, but that's understandable as there are layers within layers and it's not a straightforward topic. Baylibre are an independent (kernel focussed) software development company. Amlogic has subcontracted development tasks to Baylibre in the past, e.g. core board support for the AXG platform used in smart speakers. LibreComputer also outsources a range of development and support tasks to Baylibre which is awesome because the quality of work is high and it's been done in a way that benefits the entire Amlogic ecosystem not just LibreComputers own products. Several of the Baylibre team are kernel maintainers so they are not Amlogic's Linux support team, but they are involved in whatever action is happening. IMHO Amlogic have been quite supportive considering Linux is not their primary OS interest and we are not their customer. As with most large commercial organisations you need to understand their business model and be talking to the right people and asking the right questions to get the right response.
LibreComputer claiming "full media support" with 4.19 is over-reaching. The status quo continues to improve but there are still major items to check off the list and users testing mainline kernel images will quickly discover missing capabilities. Amlogic users tend to have high expectations so we aren't going to commence significant public testing until we reach a "feature complete" state and are ready to switch focus to bug-fixing.
If the disk is NTFS .. remove it and fix using Windows.
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.
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.
