Posts by chewitt

    I don't understand Passthrough Audio.. why do we need to enable it at all?

    Some/Many users (esp. those with ATMOS and HD-capable audio setups) obsess over quality and pass-through will ensure Kodi processing does not "degrade" their audio experience. In practice multi-channel PCM output is close-enough to pass-through in quality that the silent majority of users probabaly can't tell the difference (or don't care enough about the difference). I personally can hear the difference, but use PCM output 99% of the time simply because it allows volume control to be done from a single remote control; enabling pass-through requires me to dig up the AVR remote instead. I do enable PT occasionally for special films, but that's not often.

    In the ARM SoC world most devices have CEC support built into the HDMI hardware on the board. In the x86(64) world it's rare so regardless of HDMI or DP connection there is probably no CEC support and you'll need to add an IR receiver device. My personal recommendation would be the flirc USB receiver as it's stupidly simple to setup and works with any IR remote you have, but it's not the cheapest and there are plenty of USB IR devices on eBay etc. that can receive commands from an 'MCE' remote or similar.

    Code
            if (sector_size != 512 &&                                                         
                sector_size != 1024 &&                                                        
                sector_size != 2048 &&                                                        
                sector_size != 4096) {                                                        
                    sd_printk(KERN_NOTICE, sdkp, "Unsupported sector size %d.\n",             
                              sector_size);   

    ^ the error message in kernel code (drivers/scsi/sd.c) suggests the 256kb size is the issue so I'd suggest reformatting the drive to use at least 512kb or perhaps 1024kb and then restest to see what happens?

    Some early support for basic things like pin-ctrl and clocks are being submitted to the upstream kernel. However, the kernel maintainers require things to be done to a much higher standard than Amlogic engineers are used to, so each patchset requires many iterations and progress is proving rather slow. Ask me again in six months.

    Kodi documentation on emulators is similarly lacking. I've installed https://github.com/zach-morris/plugin.program.iagl and when I select e.g. a SNES ROM Kodi will ask which emulator to use for playback, and if not selecting one that's already present it will install one from the LE add-on repo and then things just play. There is no "Library" for games but I save regular ROMs as favourites and access them direct from there. I also have IAGL configured to cache ROM files to avoid repeat downloads and give faster starts. Other distros like Lakka, RetroPi, Batocera will be more poilished for gameplay and less polished for media. LE is more optimised for media, but the game stuff does work.

    RPi4 does not support VP9 hardware decode but it has enough CPU grunt to software decode the limited amount of 1080p VP9 content that I have for testing. It just runs a bit warm(er) over time so needs a decent passive-cooling case. Hardware decoded H264 (to 1080p) and HEVC (to 4K) playback is excellent.

    Odroid C4 should similarly support everything software decoded up to 1080p; upstream Linux support for everything except the media bits is solid and quite mature now. You might need to disable hardware decoding completely to solve the H264 issue; the current H264 support in the upstream kernel uses the VDEC driver for GXBB/GXL/GXM boards. Newer G12A/B and SM1 boards need to use the newer (and badly named) HEVC driver that supports H264, HEVC and VP9 codecs and there's an issue with 10-bit/4K media. After a multi-year wait someone is currently known to be working on a sponsored rewrite of the HEVC driver .. although I didn't see code to test yet.

    The only way to ensure something 100% boots from SD is to erase eMMC (preventing eMMC boot) or to use the special HDMI dongles that force different BL1 (silicon bootrom) boot priority. However, for reflash of eMMC you only need to ensure that the kernel is running from SD card. The initial u-boot stage from eMMC and then discovery and boot of kernel and userspace files on SD is fine since the binaries that run are on the SD card. If you attempt to flash eMMC when booted from eMMC it will start and the lock-up when you overwrite the apps that you are using to perform the flash.

    Code
    [   52.388210] sd 1:0:0:0: [sdb] Read Capacity(10) failed: Result: hostbyte=0x00 driverbyte=DRIVER_OK
    ...
    [  215.015888] sd 1:0:0:0: [sdb] Unsupported sector size 67108864.

    The physical drive is detected, but I see ^ those two errors reported and there is a three minute gap between the initial probing and then a disconnect and second probing and there is no attempt to mount filesystems.

    I didn't find anything from some initial Googling on the errors, but things point towards 'geometry' issues. Was the drive formatted under Windows? .. If yes, what was the sector size used? - Do you have any other PCIe > USB cases that can handle the drive?

    We don't support LE 10.x/11.x on the 3A+ due to the 512MB RAM configuration (under 1GB will not give a good experience). Older releases like LE 9.2.x are more efficient on 512MB boards due to the older video pipeline; although the boot firmware in our older images is older and doesn't always support the latest revisions of earlier Pi hardware. That's not the issue here (the error looks more like an SD card creation issue) but something to be aware of if/once you get it to boot and then find the performance underwhelming.

    LE has lots of binary emulators available although the Kodi GUI doesn't do the greatest job of helping users understand which ones work ok or best on any given piece of hardware (an RPi4 will not handle everything). If you do a little research things run fine from LE.