Posts by chewitt

    In LE the xrandr command is only present on devices running Xorg/X11 windowing (Generic x86_64 devices) but ARM SoC devices "run on the framebuffer" with no windowing system. Other distros, e.g. Armbian are desktop focussed and will use X11. The nearest equivalent is forcing kernel DRM output modes, which can be done via boot params in extlinux.conf.

    I don't have experience with SCART devices, but the standard resolution I've seen with RCA outputs (single cable) in the past is 480p/i and it's cousin the Component output (three cables) is the same but can also run at 720p and 1080p/i. Current Kodi skins are designed for a minimum 720p screen resolution but most (not all, but most) will handle 480p if needed, but lower than that I'd expect to see visual problems as none of the skin designers will be testing low resolutions. Similarly.. I doubt any of our maintainers are testing RCA/Composite output so YMMV.

    Right now there's really only one developer working on Rockchip (others had to step back for personal reasons) and people have lives outside of fiddling with kernel drivers and their own sense of skillsets and where focus needs to be. There's also a lot of collaboration happening on hardware video decoders (V4L2-requests needs to work on three different SoCs we support) so it makes sense to be involved and contribute there. Meanwhile PCM audio is working and good-enough until time frees up for other things.

    It depends on your knowledge/skill level. Our recommendation is still that most users do a clean install to avoid problems with add-ons which need to be replaced. If you're comfortable with the SSH console and know what files do what in Kodi, it's simple to rename the current Kodi folders out of the way, update to 10.0, then stop Kodi to migrate the important bits back into the new clean-install Kodi folders and then restart Kodi to finish the job. As a broad rule: if you don't get/understand the hints I've just dropped .. do a clean install, and if you did get them .. Good luck and off you go.

    Index of /testing/ has an LE10.0.0 "box" image for WP2 (vendor u-boot) or brave souls can erase the emmc and then install mainline u-boot (to emmc) via the "wetek-play2" image but support for hardware decoding in the upstream kernel is still a bit rough and the DVB tuners are not supported. These days fewer people are shipping DVB cards in-box and my advice would be to separate "head end" with tuners that is accessed over the network from a dumb(er) "client" device. If you need the tuner and the WP2 still works; you can keep it going with current software just to serve the tuners while using a newer client device.

    4K/HEVC and 1080p H264 is handled well in RPi4B, but it is missing VP9 which (along with any other codecs) is software decoded, the chip has lots of grunt though so up to 1080p that's not a big issue. Allwinner/Rockchip have continuous ongoing work around the hardware decoders but they are now quite mature and shaping up .. but there's a mix of older chips and newer ones and it's a little confusing. Amlogic (LE) has the same issues on G12/SM1 boards as the WP2/GXBB device you have (if anything they are worse, the newer chips have more complicated HEVC/VP9) but CE with legacy vendor kernels is a better option, but AFAIK they do not have DV running. OSMC does support it in their Vero 4K box, and you'll find Android devices that do it (but that's not my area of expertise).

    Not sure that helps. I'm personally a fan of the RPi4B. There are lots of devices with technically better specs but it has (and will continue to have) great software support and IMHO that's the most important thing for longegivity of devices.

    dtech see if you can backport systemd/busybox: allow configuration of persistent logs and journal by mglae · Pull Request #5537 · LibreELEC/LibreELEC.tv · GitHub and then use /storage/.cache/journald.conf.d/00_settings.conf with something like:

    [Journal]

    SystemMaxUse=10M

    MaxRetentionSec=0

    RateLimitInterval=0

    RateLimitBurst=0

    The settings add-on changes are in Add persistent logs and journal configuration by mglae · Pull Request #233 · LibreELEC/service.libreelec.settings · GitHub but we rewrote/restructured most of the settings add-on since 9.2 so those won't backport.

    HC4 is powered using a barrel jack (15V-4A) and the drives are connected via standard SATA connectors, not USB. This device was designed to be a NAS device and HardKernel have been designing this kind of things for years (not the first cloudshell design/product they sell) so while testing for voltage drop is something to do - I'd be surprised if it's the reason.

    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.

    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.