Bad PSU, Bad SD Card, User not waiting until things actually shut down?
There is no general "reboot issue" with the RPi4 image so it's something local.
Bad PSU, Bad SD Card, User not waiting until things actually shut down?
There is no general "reboot issue" with the RPi4 image so it's something local.
We already have a USB/SD Creator app for Windows on our website and we distribute a simple .img file that can be restored to a USB/SD card using a dozen or so different tools that require no integration or effort. We have no plan to ship an .iso image which is what that tool appears to want.
Reboot and things should be present now, someone forgot to create some aliases on the webserver (RK3399 uses the Tinkerboard addons).
What OS are you using to build with (distro and version) ?
Master has bumped to Python3 .. possibly a little prematurely, but at least it highlights where all the issues are.
So I think this patch series will be required (it's the fix for the problem, not the cause): U-Boot - Patchwork
Can you test?
Download "handbrake" and transcode it to H264/H265 on the desktop machine. Time to transcode will be shorter than time looking for a Pi based solution that doesn't exist.
chmod +x /path/to/autoexec.py ??
It's technically possible if you run Chrome in a docker container .. which means you cheat by running a full general purpose distro like Ubuntu in the background to gain the X11 environment needed for Chrome. TL/DR; It will run, but the performance should be pretty sucky at the same time.
Can i ask which is the more advanced build
Milhouse images are based on Kodi Matrix (v19-pre-pre-pre-alpha) and the LE 9.2 codebase is based on Kodi Leia (v18.4). Milhouse normally curates his images to be fairly stable despite the bleeding edge code, but right now the Python 3 bump in the Matrix codebase makes that a serious challenge and you should expect some breakage.
Mainline Linux kernels have zero support for Amlogic's proprietary 'Android' partitioning scheme (and there's no plan to change that). If you use a decent SD card or USB the speed difference against internal eMMC storage is negligible. If you use some cheap old device, for sure it will be less snappy.
Win10 needs authenticated access to an SMB2 or SMB3 share. In LE this means you will need to enable the Samba password in LE settings before trying to connect to the Samba server.
S905X2 needs a newer kernel than the S905X and "internal" install is not supported (old kernel scripts will not work on a mainline kernel). There is no plan to support this in the future either. Use an SD card or USB.
sem problemas ![]()
Lima/Panfrost are about OpenGLES, not hardware decoding.
Armbian has the same hardware decode capabilities as LE since 99.99% of the kernel is the same (mostly based on one of my branches). Amlogic GX is in reaonsable shape and G12 is missing some bits but improving. That said, in the imminent future there will some deliberate breakage as the vdec drivers and firmware need to be revised for V4L2 compliance (stateful API things have been formally documented for the first time) and the changes will necessitate some replumbing in ffmpeg and tweaking on the Kodi side - which will take some time. Progress is coming in fits and starts at the moment as the whole GBM/V4L2 ecosystem is still rather fluid, but the overall mainline codebase for Allwinner/Amlogic/Rockchip continues to improve nicely. One challenge you might encounter with Qt is that V4L2 support was originally authored (by an LE/Plex contributor) about 18-months ago now, and that probably means it's no longer "compliant" with current kernel and player (mpv, ffmpeg, gstreamer) code. It's not something I track so I'm not sure whether anyone is maintaining it.. I know the original LE contributor is not, due to other life priorities.
Hi,
How do I know if I have the latest firmware on Pi4?
The menu appears like this, "Bootloader EEPROM (up to date:2019-09-10)"
Thanks for the work...
^ what's not clear about "up to date" ??
Sorry, just to clarify, when Linux 5.2 is the base for Libreelec, that's likely when the os will fully support 4k and HDR with the Pi4?
I'm curious so that I know for future reference. (I may consider a Pi4 then)
LE master branch is already on 5.3 and will bump to 5.4 soon .. but not for RPi4 which needs to remain on 4.19 until more V4L2 plumbing has been completed. Kodi is slowly inching towards HDR support. It's already possible to hack something up that works for some SoCs (not RPi4 yet) but we'd rather do it properly at a more measured pace. I'm not expecting to see "proper" HDR support for some time yet.
I asked one of my kids to guess at the problem, she said there's probably a software issue. It's a vague answer, but without a Kodi debug logfile to show us what's happening (or not) it's as good as any other guess ![]()
You can add the Confluence skin to Kodi v18 (from the Kodi add-on repo) but you cannot run Kodi v17 (or older) on RPi4 - core hardware support for the RPi4 does not exist in older releases.