Posts by chewitt

I haven't had any contact with afl1 for 18+ months and I have never knowingly been in contact with any MeCool developers.

I do have direct contact with Availink who create the demod chips, but their repo is quiet since the summer (no idea why) and I haven't spoken to them for a while either. I got their new demod driver to compile, but quite a bit of work is needed to disentangle all the other drivers (tuners, demux) from their code so that each driver follows kernel APIs and can be independently compiled. Someone also needs to write a V4L2 deinterlace driver because we cannot use the Amlogic vendor drivers; it's written against a bunch of proprietary APIs that don't exist in the mainline kernel.

TL/DR; I wouldn't expect to have "integrated" DVB stuff working anytime soon.

Changing the wireless properties is not supported and the authors of ConnMan have historically resisted the idea of adding that capability because the current-coded feature is intentionally a mobile phone "hotspot" and not a "wireless accesss point" manager. You'll notice that your phone doesn't allow anything more than SSID, passphrase and on/off either. If you need a router .. you need to get a router.

If multiple distros that work "out of box" with pi hardware fail to get audio out of the board, it sounds like a hardware problem. It's rare, but does happen.

You can set folder permissions to make media (content) read-only. The only devices I know of with a switch are full-size SD cards, but you would not be able to use these for the boot device as the OS still needs some writeable /storage for itself.

Use SSH?

Seeking is not-working in the DRMPRIME stateful decode path (H264 on all Pi boards) and the same issue also affects Amlogic, iMX6, etc. which are also stateful decoders (HEVC on RPi4 is statelesss and works fine). If you disable DRMPRIME you are software (CPU) decoding which works fine but you may struggle to decode higher bitrate content. It's a long-running issue that hasn't had a eureka moment yet, and it's the primary reason we may not initially release RPi images for LE10.

You could include them in our repo too of course, but that ideally requires them to detect and gracefully error when install on non-Opi boards since we are now publishing a common set of ARMv7/ARMv8 add-ons and they'll be visible to users of any ARM device. You can use "dtsoc" and "dtname" to read the device-tree compatible strings.

His name might be kowalski but that doesn't make him Polish (close, but not).

I haven't looked (and don't plan to) but I'd make an educated guess that most or all of the drivers you're using are not from the upstream Linux kernel, which means they are written to the whims of a vendor instead of conforming to a common kernel-dictated method for reporting values. DVB drivers are one of the most-icky bits of our codebase.

There is no official "GBM" project/device so smp needs to override the add-on configuration when building images to use 'Generic' add-ons. Once that happens and you update to a version with the change, you'll be able to see Generic add-ons.

You should look at creating a repo for the add-ons so that users can install the repo, then install the add-ons, and then receive updates to the add-ons when you push changes (fixes/enhancements) to them.

As HiassofT already stated, the media is 10-bit H264 so the Pi is software decoding it tto 8-bit and doesn't have enough CPU grunt to do this without dropping frames. Nothing supports HW decoding of 10-bit H264 because it is not a broadcast standard, so most people who need this (Animé fans) use a decent Intel x86_64 CPU device that can handle the task.

The project team are all unpaid volunteers writing HDMI and related HBR audio code from scratch and upstreaming it (slowly) to the Linux kernel in their private free time whilst having busy professional and family lives. If you feel progress is too slow, feel free to contribute the changes faster yourself, or fund a professional development house like Collabora to do the work, or continue using Android.

You're copying from exFAT (FUSE) on the stick to EXT3 (kernel) on the drive but both are external devices are attached to the same USB bus, and while the devices might be whizzy USB3 ones the Pi board only supports USB2. It's not a combination that results in high read/write performance and you can somewhat prove that USB is the bottleneck by test copying the file to the SD card. It's still not going to be high performance but should be noticably faster. NB: Kodi cache settings have nothing to do with disk read/write performance.

Interesting. We've no objections to someone figuring out the changeset and sending a PR for testing. That said, at this stage in the v9.2 release cycle we might nip/tuck something that solves a problem but we won't bump packages (esp. not ones that haven't been touched in aeons). So you'd need to target master branch.

NB: If you're going to spend effort on NTFS things I'd be interested in Linux FS Development - Patchwork which should backport onto Linux 5.9/5.10. It's likely to merge for Linux 5.11 which will open its merge window shortly after LE10 ships, so the timing prob. doesn't match up for the initial LE10 release.

The build system will not work on OSX. Oracle VirtualBox is $0 if you need something to run a VM with.

I'd guess the USB drive has an NTFS or exFAT filesystem, so in LE 9.2 you're using FUSE (userspace) drivers which are known to be much slower than kernel drivers (which don't exist, hence using FUSE). RPi2 also has Ethernet attached to the USB(2) bus which is also moving data too/from the disk at the same time. It's a horribly inefficient combination, and other compute devices have a) lots more CPU, b) peripherals on independent buses, so it's really an Apples v Oranges comparison.

First thing to do is show us the entire (debug) kodi.log .. not the one line showing a harmless (and thus irrelevant) error message.