Posts by chewitt

Correct, the BCM2711 in an RPi4 is essentially the same BCM2837 chip used in the RPi3/2/1 (with the same capabilities) but with HEVC from a Broadcom IPTV chip bolted-on to handle the 4K HEVC (8/10/12-bit, HDR) needs of the 99.9999% of 4K media in circulation. It's rare to find 4K H264 in broadcast media, and other ripped content can either be re-ripped or re-encoded easily.

Do you get CVBS output if you disconnect the HDMI/VGA device? .. the hdmi_group/mode/ignore_edid settings no longer work in LE10, the kernel DRM subsystem manages output now (same as all our other devices).

Odroid HC4 = "NAS" with user-provided (in this case Seagate) drives, the NAS is not something separate. HC4 has SATA/PCIe hardware and a good PSU so the drives are well powered and cannot be externally powered.

APPEND is a syslinux/extlinux thing. The main boot params are boot=/path/to/KERNEL and disk=/path/to/storage .. the init script embedded in the kernel will find SYSTEM in the same location as KERNEL so there's nothing to set. The only other params normally on the APPEND line are to redirect console output and quiet to silence output to screen. I'm not sure the rootfstype is required, the init should detect the filesystem used for disk= and use whatever is needed.

Have a look at LibreELEC.tv/init at master · LibreELEC/LibreELEC.tv · GitHub

I'll tease you with "work on deinterlace has finally been started" .. but while that's great news, deinterlace requires V4L2 driver/ffmpeg code to be imagined from scratch, with more blind guesswork and experimentation than normal. It's also not the highest priority in the queue for the Pi Foundation folks who are looking into it. The main positive is: the only other known attempt at V4L2 deinterlace (which works, albeit with some rough edges) was done by our Allwinner maintainer so that knowledge has been easy to share. I'm not expecting it to be a quick feature .. it will take time to get first-pass working code, and then it's going to take a pile of testing to iron out the issues.

Odroid C2 is a nice board, but it launched in 2015 so it's not something to consider today. Lots of devices based on Amlogic, Allwinner and Rockchip chips are technically more capable and cheaper than an RPi4 but the software support is always going to be more challenging. RPi4 does 4K, hardware decoded HEVC, HDR, and HBR audio and it will receive the same A1++ software support you've seen on older Pi devices.

4K = Yes, HDR = No.

There are some experimental images in a thread from smp which enable current Kodi HDR support for some Intel GPUs. HDR works well in some areas, but is still "work in progress" in others, hence we didn't switch from the Xorg graphics stack yet.

Run chkdsk.exe and then unmount cleanly before detaching the drive.

Unless you have a specific issue with the LE10 releases (add-on compatibility or a missing feature) .. run them. LE926 is ageing now.

If an NTFS drive is flagged as read-only the drive is probably seen as "dirty" e.g. it wasn't cleanly unmounted from Windows, so you'll need to either fsck the drive in Linux or remount to Windows and fix there first before Linux will mount it read-write. NB: NTFS does not support Unix filesystem permissions. This means all files will have 777 permissions which should also ensure any user (inc. root) can write to the drive.

sailorpito update with LibreELEC-AMLGX.arm-10.0.0.tar and audio should appear? share dmesg again pls.

sailorpito It looks like there are no sound/audio nodes in the current device-tree which explains why there is no audio devices showing up. I can look into adding them in a couple of days once I return from vacation. If you can pastebin the contents of dmesg and Kodi debug logs it would be useful.. ISTR the current device-tree was a blind guess so it will be useful to validate what other bits are showing or not.

The "find -mtime +7" option looks at filesystem timedate stamp (not filename) and the screenshot clearly shows all files as being created (or touched) on 22/8 so they are not in scope for deletion.

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.