"Feedback is welcome via the forum, but please do not expect support"
Thanks for the feedback. No further action required.
"Feedback is welcome via the forum, but please do not expect support"
Thanks for the feedback. No further action required.
Most of the LE filesystem is read-only which would explain the permissions error. You need to use a writeable area like /storage or if using a removable drive, somewhere under /var/media/<drive> where the drive is auto-mounted. I'm not anywhere near an LE device to check but I'm not sure /media is a valid location in the OS.
If you are unable to umount the drives something is using them and this needs to be stopped first. If they are removable drives; disable the samba service which is auto-sharing them .. that's probably the reason.
If you apply Pulse config via /storage/.config/pulse-daemon.conf.d/daemon.conf it will be processed at startup and overrides the embedded config file before Kodi starts. The other alternative is creating a systemd service file in /storage/.config/system.d to run commands or a script with dependencies to set when in the boot sequence the service is run, e.g. after Pulse and before Kodi.
Run "getedid create" from SSH with the Pi connected to the powered-on TV .. it will dump the EDID data from the HDMI connection to a file and change the boot configuration to use the file; then the Pi always sees the TV as connected.
That's a WeTek Play 1 (WeTek OpenELEC) box (8726MX chip) not a WeTek Core (S812). NB: dtech If you do find a Core for sale anywhere that takes PayPal we're happy to fund it.
Kodi supports multiple weather add-ons, depending on where you are in the world, but these are not "apps" that you can do things with from the SSH console. Under the hood the add-ons are just fancy Python scripts that poll online sources for data and populate that data (via APIs) in to the Kodi GUI. I suggest you start over by explaining what you're trying to achieve in more detail.
Have you experimented with the 4K60 enable options? .. If those are set and the TV supports 4K it will try to use them, and then we often see issues with cheaper cables.
touch /storage/.update/.nocompat
wget https://releases.libreelec.tv/LibreELEC-RPi2.arm-9.2.8.tar -O /storage/.update/
reboot
^ I think you should be able to just SSH into the console to download the correct image file and cross-grade to the RPi2 image. You need to disable the compat check with the touch command else it will flag you are using a different image and abort the update.
I've no idea. I've never bothered with skin editing to set defaults because the effort involved will be greater than just setting the view type the first time I navigate into some new part of the Kodi GUI.
Each section of the Library (Movies, TV Shows, Collections, etc.) has its own view type so users are sometimes confused by why changing the default view is not a single global change and they need to set it again in other sections (each section) but once you have changed a section view and leave that section of the GUI it should remain changed. You will not be able to edit the skin xml files directly as they are located in a read-only filesystem.
The knowledge hasn't been lost, but the patches to make it work are large and invasive and much of the code needs to be rewritten from scratch as GBM/V4L2 works completely differently. The work is not impossible to do, but one goal of the GBM/V4L2 work is to upstream everything so that all distros have good media performance on Pi hardware (with a focus on RPi4) not just LE/OSMC who were mad enough to entertain a 50,000 line patchset in the past. The nature of the changes needed for optimised HEVC means they will be hard cum impossible to upstream, and while the percentage of LE users that might want the patches is high, most other distros with an actual patching policy refused the existing patches, so the total percentage of Pi users (all distros) that want the patches is low - and hence the Pi Foundations motivation for reinventing this capability is pretty low. Forcing updates is not their motivation at all, but a few users updating to RPi4 to gain more features including hardware HEVC decode doesn't hurt either.
I have all devices that need performance connected via Ethernet but for dev work I'm often fiddling with something in a location that doesn't have an Ethernet cable nearby and the device doesn't have working WiFi support. I solve that with an old Apple A1rport express in bridge mode .. the last one I picked up from eBay was $12, and all I do is plug in a short-ish Ethernet cable to the device and ta-da it's on the LAN.
The upstream kernel is full of "prior art" https://github.com/torvalds/linux…t/dts/allwinner and would be my starting point. I don't see any existing H313 device-trees though, so I suspect your quest needs more fundamental "board bring-up" in the kernel than a device-tree file.
I've moved the thread to the Allwinner section so others comment.
Our userbase has a large number of people using DVB features with RPi2/3 hardware so we are waiting (and actively working on) hardware deinterlace support. Once that's in a public-testable state we will probably release an LE10.0.x "beta" for RPi2/3 users and encourage people to shake out the issues. There will still be a moderate percentage of pitch-fork waving villagers complaining about the loss of optimised HEVC support too; but since that's unlikely to be reimplemented we'll just have to weather that storm.