Posts by chewitt

vpeter so I can see that the dual/quad versions all share the same u-boot defconfig, which supports the idea of consolidating images to three: cubox, udoo, wandboard. I can also see that wandboard has more dtb's than we currently create images for (revb1, revd1 were added upstream). It's simple to repackage and accomodate that, see Commits · chewitt/LibreELEC.tv · GitHub and I think the simplicity of image naming trumps adding more dedicated images (and I'm doing the same thing with Odroid N2/N2+ in the next Amlogic bump). I'm interested to know what happens when users with a quad board don't change the dtb name and boot using the dual dtb? (or should the defaults be switched to quad?). Also, looking at the device-tree files in the kernel, didn't we (you) also used to ship an image for the Hummingboard devices?

It might be missing the firmware, in which case you'll need to share "dmesg | paste" output so we can see the error message that tells us which file can't be found (so we can pick/add it).

I think the current plan is to use GLES shaders to handle the conversion. The shaders are already well known. The plumbing to use them with the all-new RPi video pipeline is not, we (mostly the Pi Foundation folks) will need to invent and implement more new stuff. HDR is also mind-bendingly not simple so I wouldn't expect this to happen too quickly.

The 2GB or 4GB versions are fine, there's no need for 8GB unless you plan to do other things with the board.

The beelink-s922x image on that page is designed to overwrite the internal emmc storage. It's not something you can use to boot the factory box from as vendor u-boot doesn't understand extlinux boot configurations. You'd need to boot from the box image first, then use 'emmctool' to overwrite emmc with the beelink image, but due to an issue which I haven't pinned down yet, when you attempt high I/O load when booted from vendor u-boot the box will deadlock and probably leaves the device in non-bootable state. It's possible to recover the box with Amlogic burning tool and a factory ROM image, but not everyone finds that simple. So you're welcome to experiment with those images but I do not support them. If you mess up your box, it's not my problem to help you sort it out.

I can see that you have GitHub - KODeKarnage/script.lazytv: XBMC Addon - LazyTV installed which wants to "recommend" things to you, although it sounds like it works more with the local library than add-ons. You look too be repeatedly playing ЧЕСНИЙ ЗЛОДІЙ. Офіційний трейлер (український) HD - YouTube (Ukrainian not Russian). Perhaps move /storage/.kodi to /storage/.kodi-old and start over, move DBs and add-on settings back bit at a time until you find the problem?

btw, the old OpenELEC repository.unofficial.addon.pro is still installed, which is unlikely to be useful these days.

In current nightlies (LE10) the HBR audio will work, but there is no 4K or HDR support. In current stable (LE9.2) 4K works, but there is no HDR and no HBR audio. Current develpment priority is getting the H264 hardware decder working with GBM/V4L2, then 4K, then 10-bit, then HDR .. so lots of work to be done.

vpeter I have no recollection of years back ideas because back then I had no clue about u-boot and wouldn't have understood the conversation. I'm less ignorant about u-boot these days but I don't know the specifics for iMX6 SoCs. If you're prepared to educate me a little and share the idea(s) that you had, I'm happy to listen.

LibreELEC-iMX6.arm-9.80-nightly-20201207-edb090e-cubox-q.img.gz <= the cubox-q (quad) file is the one to use. I think the cubox image names could be improved.

vpeter if you have a better idea on how to handle things I'd be happy to hear suggestions or see a draft PR.

btw, Kodi does not (and never has) supported shared thumbs via pathsubstition. It's unlikely to be the cause, but it does sometimes cause problems.

In LE 9.2 there is no support for HDR in the RPi4 image so HEVC files will play with washed out colours. It's currently the same in LE10 dev images but we're nearing the point where some of the plumbing for HDR falls into place, and then we can start figuring out how to use shaders to remap colours so HDR > SDR works on non-HDR screens.

Quote from elonesna

Conclusion: LibreELEC configures itself to turn on the TV during the installation process.

The conclusion is wrong. LE does not turn on the TV, but Kodi stores the active video output interface in /storage/.kodi/userdata/guisettings.xml so if you install with HDMI2 and then change the interface to HDMI1 this invalidates the stored configuration.

I use a Bonjour/Zeroconf broadcast app called "Discovery" to track test devices in my network as the IPs change over time (due to DHCP) and when I clean install a new device I can see the SMB share appear in the list (so Samba is active) and then when I enable SSH and disable Samba in the first run wizard; Samba disappears from the list and SSH appears .. i.e. the respective services are being correctly stopped/started.

I haven't touched Samba and SSH. Both work for me

The last LE image for WP2 that supports the internal tuner is LE 9.0.2. I'm not sure what you think is incomplete about it?

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.