Posts by chewitt

The profiles capabilities in Kodi are neglected/broken for a long time and need to be removed and then redesigned/reworked .. but it's a non-trivial task with a lot of impact on code and so-far nobody has volunteered to do it. That doesn't answer the question - but hopefuly (re)sets your expectations on profiles.

I can run the same command successfully here, so I think this might be a Windows line-endings issue which results in something being added to the command that "find" can't interpret. Run dos2unix on the file and see if that fixes the problem?

jock2 When people first went looking for the SSV6051P driver some sources were found on GitHub and there was a theory the chip was a clone of a Realtek part. Some of the sources had a bash script for changing what appeared to be realtek IDs for SSV ones, and sources had similar structure to old(er) Realtek drivers. I forget the details now, esp. what Realtek chip was hinted, but someone attempted to recreate the same process and didn't get anywhere with it. Not that suprising really.. and the whole Realtek theory could be a red-herring.

Also for background: One of the Rockchip devs (these days ex-Rockchip, but native Mandarin speaker) did some research for us a couple of years ago and told us SSV went bust in 2016, but the assets appear to have been acquired by icomm, and 新闻资讯-深圳市南方硅谷半导体有限公司 shows blog/post activity dated from April 2020 - and since I last looked at their site (a couple of years ago) a range of new chips appears to have appeared. The icomm website claims the company started in 2018.

If the idea of a rewrite ever moves beyond the idea stage keep us posted. We'd be keen to offer support; even if only the moral kind

The tearing issues are long solved in the 10.0 codebase

Quote

About ssv6x5x, I did not even try it on mainline kernel, it is a miracle it compiles and works on legacy 4.4 Probably the drivers requires a complete overhaul to work well with mainline kernels. Its sibling, the ssv6051 driver, has been left behind by rockchip itself in the jump to the 4.19 kernel they recently made. ssv6x5x and ssv6051 are very similar, and both of them are incredibly messy!

^ from a later post in the same thread you found. Armbian often uses legacy vendor kernels to support devices. That thread is using the Rockchip 4.4 kernel. There are major crypto changes around 4.12 that break the drivers.

Quote from KingAsta

I have an MXQ Pro 4k with RK3229 and wifi chip SV6265P

SV6265P sounds like a Silicon Village chip. If yes, the company went bust in 2016, their drivers are the worst garbage I've ever seen, and there is little hope of seeing a working mainline Linux driver (needs a ground-up driver rewrite, which is unlikely to happen).

Could be a missing driver, missing alsa conf, bad EDID from the TV on the HDMI cable, bad HDMI cable, or something else.

Windows does not understand Unix filesystem permissions, so while you can edit the file it will add new files with the equivalent of Unix 777 permissions. It's not a major issue for samba.conf, but make sure the file has Unix (not Windows) line endings as that will be an issue.

If you want things perfect, edit/add the file on the original system and take a new backup.

If autostart.sh feels like a hack you can always convert things to a systemd service

I'm the only staff member who has ever owned a Mac Mini (and mine was older and never ran Linux) so our collective knowledge on them is rather poor. I have fuzzy memory that devices before the "late 2010" generation don't support audio on the DisplayPort connection so you would need to output audio on the headphone or optical outputs, but that still requires audio hardware to be detected. I'm not sure what hardware provides those functions. Start by sharing logs (dmesg and Kodi debug).

NB: As a semi-serious suggestion: I would refurb and eBay the device, and put the funds towards an RPi4 kit, which will be better/easier.

I'm not sure if this image supports it (or the drivers, due to kernel age) but if there's an option in the settings add-on for wireless regulatory domain; make sure this is set for your country so that radio properties are correct for the router.

Lesson #1 for all remotely supported tvbox devices is .. make them use Ethernet. Yes the cable is inconvenient. Yes it will save you many hours of remote support effort. In situations where I've been forced to use wireless I prefer to recycle an old Apple A1rport express device so the less-than-reliable TVBox OS is still connected via Ethernet, because ancient vendor wireless drivers in ancient vendor kernel have limits on what they will support reliably - I prefer to remove them from the equation.

Not impossible, but as they observe, there is no apt-get so you need to build dependencies into the image. Easiest would be a custom image that adds pigpiod and other bits to the image and IIRC WiringPi is one of the Pi add-ons in our repo. Once you've gotten to that stage it's not a huge leap to then repackage things as a binary add-on that can be submitted-to and then installed-from our add-on repo. The demand is likely not that high though, so I'd build it for yourself and push the sources to a GitHub account so that anyone else seeking the same can repeat the process.

Options=username=<username>,password=<password>,rw

What happens if you remove the version forcing and let things negotiate normally?

At launch there were 1GB RPi4 boards, but 2GB is now the minimum configuration and this is fine for Kodi use; the 4GB or 8GB boards are also good. These days most users have media on a NAS accessed over the network or an external USB drive so a kit with a less expensive 8GB or 16GB SD card would be fine, there's nothing in LE that would ever really need/benefit from a 128GB card.

At some point we will dump Xorg and switch Generic to GBM/V4L2, but we're aware of a number of HDR related use-cases that still need work (in drivers and in Kodi). However the devs who've been working on this are limited in number and right now real-life is rather busy for them, and K20 is super-early in the dev cycle so we're not in a rush.

I'm not sure what the cause/problem is but I've seen this at some point recently too. You can SSH into the box and use "bluetoothctl" to perform the pairing as a workaround. Same basic process (as the settings add-on drives the same API) but no GUI to go wrong.

Nothing has been done to explicitly alter or change 3D support. That said, nobody on staff uses 3D so it wasn't tested either.