Posts by chewitt

User posts about low-quality Realtek device delivering low-quality performance. LE staff feign surprise and advise user that the $2 USB wireless thing they purchased is garbage. User asks for officially supported and recomended alternative cheap USB wireless devices. LE staff refuse to recommend anything because all the cheap USB wireless stuff you can find is similar garbage. LE staff recommend a wireless bridge that presents Ethernet to the RPi2. User protests that $20 (for a used Apple A1rport express on eBay) is an outrageous idea and makes pithy comments about our decision to not add more low-quality realtek drivers to our distro (so they can purchase the latest expensive USB Realtek wireless garbage instead of older cheap garbage). Eventually user gives up and gets a wireless bridge that just works and the pithy comments stop.

^ is usually how these threads play out..

It's unrealistic to expect add-ons built for our current distro to work on OE. It's ~4 years since we abandoned OE to its problem creator and in that time we have maintained and evolved our codebase. Things look familiar but under the hood they are programatically different. The sole solution is updating the OS/distro. Use docker or look at the Thoradia thread for torrent apps if you really need them. If you really want it to work in OE, please ask for help in the OE forum .. although good luck in finding a real user (it's mostly spam-bots).

Tvheadend web interface on port 9981

It just means the wifi chip will not work. The chip copies (is ripped off from) a Realtek design but with enough differences that you can't simply add the chip IDs to the existing Realtek driver, and the existing driver source for Linux 3.14 "works" but is garbage code. We had a stab at forward porting to Linux 4.20? (it was some time ago) but with no documentation and badly written code to start from it wasn't a fruitful expedition and we gave up. I also had one of the Rockchip staff (native Mandarin speaker) do some phoning around and he confirmed SSV went bust in 2016 so there's never going to be newer official sources. The latest kernel the current driver will run on is Linux 4.4. After 4.4 you run into significant crypto API changes (needs a major rewrite) and this stops the driver from working.

Mainline kernel doesn't have same hard-coded 1GB/2GB device-tree silliness as older kernels. Wireless chip is the SSV6051P .. the same crap cihp that's in the Tanix box. There's no support for that chip under mainline kernel (and unlikely to change).

You can have a look for a Docker container .. or if you have any dev skills, add a package to our network-tools add-on.

I've a Tanix TX3 mini which is the same spec (1GB/8GB and also S905W) purchaded off eBay for $18 a year or so back. The TX3 device-tree will probably work on is as most of these ultra-cheap S905W boxes are carbon copies of the Amlogic reference board. It likely only differs in choice of wireless chipset.

If the issue is with the add-on the correct place to ask for assistance is the add-on support thread in the Kodi forums (most add-ons have one) where the creators of the add-on hang out. It's not really an LE issue.

I don't think Docker would be a solution, it's a userspace abstration that doesn't interact directly with hardware.

No different from previous Pi boards .. although overclock settings will be different. I'm not sure you gain much though, it's a fast board already.

Nope. Milhouse images are always bleeding edge code. I'm not sure he's releasing for RPi4 at the current time though (having looked).

If fuzzy memory serves right, there are two components required. The add-on in our repo connects Kodi to hardware, and the LCDproc add-on in the Kodi repo is used to configure what you want Kodi to put on the display.

If you want a browser you will need to run a desktop OS like Raspbian. There are no browser add-ons for RPi in LE. It's technically possible to hack something using docker, but then you're just running a full desktop OS like Ubuntu in a container in the background, and you have to stop/exit Kodi to switch to the browser and then exit and restart Kodi .. not the best experience. In the future there is maybe one built-in to Kodi, but not yet.

RPiF folks are working on HBR audio but the BCM2711 SoC in the RPi4 is effectively a custom part assembled from the IP of several other chips so existing Broadcom sample code and documentation are a bit lacking - there's an element of reverse engineering involved. Video work has a higher priority right now, but audio will get there eventually.

70% of our userbase has an RPi3 or RPi2 so if there was a general issue we'd know about it. From past experience .. start uninstalling add-ons until you find the one causing the problem.

BT on/off in the settings add-on only determines if the userspace tools are started on boot, it makes no difference to hardware detection which is all about the kernel. Same for the Kodi audi-changer. No hardware is detected.

If LE has any support for camera devices it's accidental not intentional. RPi3 should have good overall support for devices under Raspian but as we have no real need for camera support there's no guarantee we have the right kernel config etc. in place. RPi4 capabilities are broadly on-par with RPi3 but the overall codebase is newer so there may be differences; don't assume they are the same.

Kodi 18.x (LE 9.2) is py2 based. Kodi 19.x (will be LE10) is py3 based. I doubt we have removed that module (we haven't touched our python config in aeons). More likely the ABC iView add-on developer started to update their add-on for K19, and instead of maintaining both py2 and py3 version of the add-on they are attempting to cheat with a single add-on and py2/py3 compat tools. My guess is they are wrongly assuming all distros have this stuff present, and they broke backwards compatibility.