Sorry.. not in Armbian forums, here on the Amlogic u-boot mailing list:
Re: meson-gxbb regression since u-boot v2020.04
and
[email protected] | meson-gxbb regression since u-boot v2020.04
Sorry.. not in Armbian forums, here on the Amlogic u-boot mailing list:
Re: meson-gxbb regression since u-boot v2020.04
and
[email protected] | meson-gxbb regression since u-boot v2020.04
Netflix does not want an official Kodi add-on due to perceived security issuess (and Kodi's reputation which is tarnished by piracy add-on shitware like superrepo) so if we push it into the official repo and/or create official documentaation to make it easier to find/install/setup Kodi will receive takedown requests; so we either make do with the current unofficial route or have no add-on at all. That's a simple call to make.
Google has also made it progressively harder to get an approved 'app' through their screening processes, and if you aren't an approved app you have restricted access to their APIs. i.e. a limited number of daily requests and Kodi has millions of users; so the daily limit is consumed fast. Google is also a commercial entity which charges for access to their services; unless you're using their official apps on their OS. There is an effort to get something through screening which might improve upon the current situation.
And feel free to write and submit an official browser add-on that runs in Kodi and works on an asssortment of Linux (including no-Window-manager environments like LE), Android, macOS and Windows platforms (Kodi will not accept platform specific features). There is an effort to do this but it's not a simple task and it's remained a one-man effort (and like all volunteer developers, he has a busy day-job). Until then the current Chrome add-on for our x86_64 releases is the only option because Generic still uses X11. Once we reach LE11 (Kodi v20) we will probably run Kodi in a windowless environoment so that route dies too.
btw, Install superrepo and you receive no further support in these forums or Kodi forums.
There's a bug in recent u-boot where a clock is set incorrectly and this impacts mmc on C2 and likely other GXBB devices. It's reported in the Armbian forums but I forget where and didn't test the hack that was posted (which is a hack not a fix).
I'm fairly sure the many authors of third-party Kodi skins might disagree with that statement.
This is not supported by the default (Estuary) skin, but is something that can be done by other skins (so i've been told in the past - I don't have any specific recommendations).
I can create 720p 10-bit H264 samples that will play, and then I can tweak the encode settings so they will not play. How your 720p files play on an RPi4 is something only you can answer, unless you share samples that others can test. NB: Animé fans normally use high-spec Intel x86_64 devices to handle 1080p 10-bit H264 media.
10-bit H264 is not an industry standard so no hardware supports 10-bit H264 hardware decode. So you must software decode, and that requires a device with enough CPU to handle the media (the PC has enough, RPi3 does not). If you share a sample someone can test it on an RPi4.
It's not a debug log, but it shows Kodi starting and attempting to open a stream via plugin.audio.radio_de which fails due to "Temporary failure in name resolution" and the LE settings add-on shows similar errors. I can't see how this is due to partymode, but I can see a general networking error that probably results from Kodi starting before the network is up; so enable "wait for network" in the LE settings add-on (under Network) and see if that resolves the issue?
The dmesg shared shows me that:
a) This is Linux 4.4 which we stopped all development on some time ago
b) Nearly every major kernel subsystem shows a catalogue of errors, so the booted device-tree is not an accurate description of the hardware
c) Including the SDIO subsystem, which the WiFi/BT device is attached to, hence no WLAN
I don't track Rockchip development closely so I've no idea whether there is a device-tree file upstream for your box, but I would start over with current Linux 5.9 based images, because then codebase is the upstream mainline kernel not the vendor BSP and there's half a chance of someone caring to assist. Old Linux 4.4 images are an archaeology trip .. and we moved on.
^ this URL gives me the icon so I'd guess the add-on in the repo has been updated to use newer add-on structure with image asssets in /resources and you have an older version (cached?) that requests a URL that genuinely doesn't exist.
Enable additional logging for curl, reboot, demonstrate the problem, then share the full debug log.
DVB is one of the more challenging bits of our codebase. Support for USB and PCI type devices improves significantly in modern kernels as several of the major vendors "got their stuff together" and upstreamed their drivers; and the upstreaming processes ironed out lots of quirky crap code. However boxes with embedded cards like Amlogic devices are still a long way from being supported in mainline so the BSP kernels are still functionally best, but also aren't perfect (and the code is horrible) and the people who championed work on them appear to have stopped work and drifed away, so they aren't improving over time.
You need(ed) to shrink /dev/sda2, then move it to the end of the disk to create space at the front, then grow /dev/sda1 to fill the gap between them that was created. Gparted can do everything in a single operation but clean installing is usually quicker ![]()
"AlexELEC" is a Ukranian rip-off release. He originally cloned OE, then LE, and now I think CE, re-attributing all the commits/changes to himself and never contributing anything back to any of the codebases - although since his images are rammed full of piracy crapware like Acestream we're kind of okay not having anything to do with him/them.
The LE 9.2.6 image works for 60k other users, so it's not the image. ![]()
Just 'update' to the release v9.2.6 image, which can be done as a manual update in the LE settings add-on.