Moved to the Allwinner subforum as the eBay listing claims it's an Allwinner H616 box
Posts by chewitt
-
-
Impossible to say without seeing the full earlier boot log (which will be challenging to collect). I'd guess a corrupted or failing SD card.
-
All you need to do is hit a key to interrupt boot (else it will do "install" the default) and type the alternative boot mode
^ ahem.
-
LE has supported "live" (temp boot from USB) and "run" (persistent boot from USB) modes in the Generic/x86_64 installer for aeons. All you need to do is hit a key to interrupt boot (else it will do "install" the default) and type the alternative boot mode. There is no need to use mkusb or other tools.
-
do you know if the database files have changed between version 9 and version 10 of LE?
Yes, Kodi major version change will always increment the DB files.
-
Borygo77 .. no support for Pirate add-on users.
-
https://wiki.libreelec.tv/configuration/edid <= Capture the EDID data from the HDMI connection and set this in kernel boot params and then the HTPC device sees the AVR/TV as always connected.
-
It's rather unlikely that our software killed an RPi board (would be the first time it happens that I can recall) and if there was a general issue or risk with software/hardware we'd have seen it lots due to the volume of RPi users we have. Was the same PSU used with both boards? - that would be a more likely route to damage.
-
LE/Kodi can do all of the above, and boring is good (doesn't involve drama/excitement and support effort). RPi4 would be strongly preferred over RPi3 these days.
-
Code
systemctl stop kodi mv /storage/.kodi /storage/.kodi-old systemctl start kodi^ that will give you a clean instance of Kodi to work with. If you have important content (thumbs/libraray/etc.) you can stop/move/start Kodi to restore individual items to the active instance. Pirate add-ons are frequent causes of problems, but that's self-inflicted punishment. In this forum you *will* be judged; by being politely asked to go look for support somewhere else if you have them installed.
-
I'd like everyone to stop "testing" and try watching some movies instead, or go play outdoors with the kids for a while instead of trying to act like uptime monitors for infrastructure that's being actively changed and fiddled with.
-
Full debug log here: https://paste.kodi.tv/jodirerixo
The log shows LE 7.0.3! .. so please find a spare SD card and try the LE 9.2.8 image.
-
Yes, if the local Samba server has been turned on (which it should be, by default). Expect tagging with Piccard to be slower though as that requires files to be read and written to the remote share. I'd suggest you map the source in Kodi to one dir on the USB, and place new but not-yet-processed files in a separate location - in Piccard you can have it move files to a new location (the source dir) after tagging. This way the filing structure is effectively managed by Piccard.
-
btw, doing some testing and I confirm that when you shutdown the box, it restarts itself again after a few seconds. I'll ping kernel maintainers on the topic but I'm not sure it will be resolved (or resolved quickly).
-
Does it mean these boxes will never get the latest Kodi? For example, if I have some sort of x96 (s905x) and could not run anything but your build on it and it was Leia, then it's the end of game with this box? I mean of course it's always possible to install Kodi on native Android, but what an unhappy day it would be...
It means there is no way to boot K19+ on devices running 3.10/3.14 kernels as support for amcodec has been exorcised from Kodi (along with a bunch of other undesirable proprietary decoders). There is some upstream development on S802/S805 allowing them to run newer kernels, although the pace of work is rather slow since there's only one developer (with a busy day-job) and there are numerous drivers needing to be written from scratch after laborious analysis of the orignal vendor code (which is horrible quality) along with ESP and blind guessing. S812 devices have the same status but with some extra issues. Right now the media capabilities aren't there so most active use with modern kernels is centred on gaming distros (Lakka, etc.) which don't need them. Marginally newer S905 hardware has reasonable upstream support (including media things) now and S905X/S912 are rather good (4K/HDR/etc. is working). S905X2 and onwards are better on CE right now.
-
Wouldn't it be better to enhance /etc/os-release with one entry what matches the subdirectory (seems to be the machine model ?) on the download server ?
You can get hints from "dtname" or "dtfile" although the device-tree compatible strings do not 100% correlate to $UBOOT_SYSTEM names for all devices we support. I wouldn't personally invest huge time in update scripts because the mid-term design goal is to facilitate switching between release and any nightly build available on the test server from within the GUI (via the settings add-on).
-
Code
cd /storage wget https://chewitt.libreelec.tv/testing/LibreELEC-AMLGX.arm-10.85.0-wetek-play2.img.gz emmctool w LibreELEC-AMLGX.arm-10.85.0-wetek-play2.img.gzIf you're feeling brave, some figuring out happened and that image ^ should result in a WP2 box that boots and runs LE with upstream u-boot from internal storage instead of SD card
-
Code
cd /storage wget https://chewitt.libreelec.tv/testing/LibreELEC-AMLGX.arm-10.85.0-wetek-play2.img.gz emmctool w LibreELEC-AMLGX.arm-10.85.0-wetek-play2.img.gzIf you're feeling brave, that ^ should result in a WP2 box that boots from internal storage instead of SD card
