Posts by chewitt

If the drive is macOS formatted (HFS+) then it's read-write under macOS but will be mounted read-only by default under Linux. It is technically possible to fsck the filesystem and force-mount it in read-write mode under Linux; but Linux doesn't officially support that so it won't happen by default in LE and I wouldn't recommend it. As with NTFS drives (different filesystem but same problem) the solution is to reformat the drive to use exFAT which is read-write supported in Windows, Linux and macOS.

Quote from MacUserAtt

Hi.

I'm using a Raspberry Pi 4 with software version 11. I'm running an external USB HDD on it. I can read the drive on my Mac with the standard username and password and copy files to my Mac, unfortunately I can't write to the USB drive, any advice?!

I'd guess the drive is NTFS formatted (default for Windows)? .. macOS only supports read from NTFS drives, not read-write. If you reformat the drive using exFAT it will be read-write in macOS (and Windows, and Linux).

Nothing has changed with Midnight Commander, but the Generic image now runs on the DRM framebuffer (GBM/V4L2) not Xorg; so 90% of the display pipeline did change and that's likely the reason. It's something to investigate, but not a super-high priority.

PROJECT=Allwinner DEVICE=H3 ARCH=arm scripts/clean linux
PROJECT=Allwinner DEVICE=H3 ARCH=arm scripts/unpack linux

I would expect that both folders are functionally the same; PROJECT patches should be applied first, then DEVICE patches. You can check the unpack (and patch) process outside of a build with ^ those commands. It's easier to spot what's included/not-included. Patch files need to be something.patch and are applied in alpha-sort ordering.

Quote from Origin

Is "legacy" or "not legacy" better for mini PC ASRock Beebox-S 7100U?

Unless you need Xorg for something. Use the non-Legacy (GBM) version.

Quote from Winneke

So i update the image manually with putting the .tar file in the update directory and reboot the device.

If running a legacy kernel release, read this: https://wiki.libreelec.tv/hardware/amlogic .. if running an LE11 beta version you can update by putting the .tar file into /storage/.update and rebooting.

LE settings > Update > If there are firmware updates of any kind they will be offered there. There have been no firmware updates for RPi3 for a while so if you've been running another recent LE release or RPiOS then the board is probably up-to-date already. Firmware updates are not always tied to an LE major release.

You can enable the Samba service in LE settings.

Changes have already been implemented https://github.com/LibreELEC/LibreELEC.tv/pull/7543

For the last decade we have been posting release announcements to our public website. Anyway, this conversation is a lost cause. Good luck and please post any further comments to some other forum.

Your download request hits our mirror redirector (running mirrorbits) which we would expect to route you to a mirror geographically close or at least in the same continent. The geo data isn't always accurate though, and with ISPs trading IPv4 address space ASNs that used to belong to someone else can give occasional random results. Or maybe the wrong number of jelly beans were in the jar today.. we honestly have no idea (and no real influence) on how it works.

Quote from Zameero

is there any solution for a S912 board that will not shutdown, but instead just reboot?

I've no idea what the issue is or how to debug that kind of thing

I think calling Generic "broken" because you can't use the Chrome browser add-on is a little over-dramatic. For the majority of users it works great. For a minority that need specific features currently tied to Xorg the GBM image is a regressive step; but they are the minority.

Kodi Settings > Interface > Skin Settings > Show media flags

Chrome requires the older Xorg windowing system used in the Generic-Legacy image. It will not work in the Generic (GBM/V4L2) image.

mount -o remount,rw /flash
nano /flash/syslinux.cfg

You need to make /flash writable first ^

We stopped formally supporting ARM devices with < 1GB RAM with LE10 as our feeling was the codebase using the newer video pipeline has outgrown 512MB devices and 1GB was the minimum needed for a good user experience. There's been no attempt to actively prevent installs on 512MB devices and stats show some LE10 users have been using it, but it sounds like things finally tipped over the edge.

The issue is likely to be RAM footprint. You can save memory in a custom image rebuilding the kernel with fewer things enabled (and more use of =m than =y) and disabling services that might not be required; WiFi, BT, Samba, etc. and perhaps experimenting with ZRAM (there's a Pull Requst for that on GitHub). All of them are marginal gains but collectively they might accumulate enough to be meaningful.

The easier option is repurposing a Model B board with 1GB RAM.