Posts by chewitt

    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 :)

    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.

    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.

    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.

    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.

    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.

    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.