Posts by chewitt

Interesting. Anyone launching a new TV box product with Amlogic chips today has two choices:

a) Use the current Amlogic BSP kernel .. Linux 4.9 supporting S905D/S912 and S905D2/S922 chips (S922 isn't really shipping yet).

b) Android .. based on the same Linux 4.9 codebase

c) Use the mainline kernel (4.19+)

The 4.9 vendor codebase is fully functional but based on lots of proprietary frameworks that originated in the 3.10/3.14 era and have been maintained and added to as time went forwards. It works but since half the frameworks originate before 4K, HDR, etc. existed it's not brilliantly architected and the code is not pretty in lots of places.

In comparison the mainline kernel codebase is architected around modern public frameworks and has more efficient and better written code, e.g. the mainline video decoder is about 10% the size of Amlogic's (measured in lines of code). However it's more of a community driven effort and it would be missing capabilities essential for a dreambox device.

Can you point me to sourced for the rumours?

In any case, a Meson6 box is stuck on Linux 3.10 which is prehistoric even by Amlogic standards. Get a cheap S905D box with GB Ethernet and you have a good tool for Amlogic learning

I assume you mean connecting an LE/Kodi client to the NAS (and not the reverse). Synology NAS work fine (we have 2x of them at home) and the only thing that's required is an authenticated connection to the NAS box. So create a "kodi" user and password, and give that user rights to shares. Now use that credential on the Kodi side - so a source will look like:

    <music>
      <source>
        <name>MUSIC</name>
        <path>smb://username:password@DISKSTATION/MUSIC/</path>
        <allowsharing>true</allowsharing>
      </source>
    </music>

^ or similar.. your NAS and share names will be different.

milhouse ^ can we revert the removal or re-add that firmware

Commercial entities posting in our forums are asked (under forum rules) to declare themselves so other users (and forum staff) are aware they are not normal users. So I must ask .. what company is the "we" you are representing?

Current 9.0 releases will ship on ye olde Amlogic 3.14 kernel. At some point between 9.0 and 10.0 we will switch to mainline. Depending on your needs or expectations the current state of things is either awesome or missing major/essential capabilities (grab a balbes150's test images if you like). IMHO there are still some key milestones to achieve before we encourage wider public testing.

If someone wants to PR a working Rockchip 4.4 device tree to Kwiboo on GitHub i'm sure he will merge the PR and we can add it to the current "Alpha" build roster. I wouldn't expect to see mainline images for some time yet.

Playing video doesn't generate much load (as it's hardware decoded) so I would assume it's fine. That's not a promise though

LE plans to drop support for the 3.10 kernel after LE 9.0 ships so even if your efforts succeed the code lifespan will be limited. It would be better to invest in a USB tuner that "just works" today and can be reused on a future replacement device (that should be running a mainline kernel).

Client and server functions will come from different binaries that potentially use different configs depending on how the binaries were compiled. It's unusual, but also not without precedent.

If you can tell us which chip is in the box .. we can advise how it might be supported (or not). Otherwise it's a blind guess. That probably requires you to open up the box.

The odd thing is that the 97-xorg.rules udev file should select the Intel GPU if present, as it evaluates in this order:

LibreELEC.tv/97-xorg.rules at master · LibreELEC/LibreELEC.tv · GitHub

Perhaps blacklist the AMD kernel driver and put a modified version of 97-xorg.rules in /storage/.config/udev.rules.d/ that removes the AMD criteria. In that scenario it cannot then choose the AMD card even if present.

Honestly.. no idea.

I'm not sure if /storage/.config/asound.conf still works as an alsa override, but you can try. That said I doubt we have all the plugins you're looking for to do complex things. You might have more success with a custom pulseaudio connection. Even then that's complicated and there's no HOWTO guide for it. It would be easier on something with Raspbian where you have GUI tools available.

SSL certificates on our repo have a validity period (start date and end date) and until the time is set the system clock has datetime before the start date so the certs are invalid and connections (correctly) fail. In our testing the WiFi performance on 3B+ is reasonable and fully supported. The current beta has newer firmware that should perform better than the first (8.2.5) release. It's also possible that a USB device with a larger antenna may perform better in your environment.

I've read the posts twice and I can see all kinds of connection info and arrows, but it's still unclear to me what you are actually trying to achieve?

There is zero support for S905X2 (and Y2/D2 or S922) and that's not likely to change for some time.

Different hardware running a different OS using different drivers and different apps = different result. Deinterlace isn't configurable without writing new code and it's one of the uglier parts of the current Amlogic kernel codebase.

The open-source group at ARM are actively tracking lima/panfrost and hope to get clearance to contribute. Regardless of if/when that comes, once lima and panfrost are viable on RK and Allwinner hardware we'll switch to them because we want to support open-source development and it will make our distro packaging a lot easier. Tracking mainline kernel and mainline mesa (which we already do) for all three platforms instead of each SoC or board needing a different kernel driver and blob will be a huge bonus. The nice thing for RK support is that we can choose when to dump the blob and switch, whereas S912 has to blaze a trail with early stage development code.

I'm expecting a few disgruntled users when we drop WP1 as it was popular and has a reasonable sized active userbase, but as the gap between the rest of the codebase and 3.10 widens we started to see breakage, and while we can make fixes there are no active team members running WP1 (or WC) as a daily-driver now so it's become a challenge to prove fixes before release. So far we haven't shipped anything untested but the number of near misses where positive confirmation is received hours before release (and after lot of nagging) is increasing. We'd prefer to stop than compromise one of our project promises.