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.
Posts by chewitt
-
-
-
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.
-
-
ozkaradag note the reference to "Raspberry Pi" VNC add-on:
LibreELEC.tv/package.mk at libreelec-9.0 · LibreELEC/LibreELEC.tv · GitHub
-
-
You've always been using GBM, but now that a recent change in Kodi supports multiple windowing systems to be supported in a single binary (which is not at all relevant to LE) the GUI was updatted to show which one is being used.