Some of their containers are deliberately missing from the 'repo' list but I'm not aware that's one of them. There's no harm in trying to use it .. if it doesn't work just rm the container.
Posts by chewitt
-
-
I don't maintain Rockchip stuff, but I add boards and such to Amlogic frequently, so:
https://github.com/chewitt/linux/commits/amlogic-5.18.y <= my kernel sources
https://github.com/chewitt/u-boot/commits/amlogic-2022.01 <= my u-boot sources
https://github.com/chewitt/LibreELEC.tv/commits/amlogic <= my LE sources
There are lots of previous examples of devices being added in GitHub.
-
It will either fix the issue or it won't .. so easy to test and try
-
LE patches generally follow <package>-<number>-description.patch but it depends on who created them and where they are used, e.g. for Amlogic kernel stuff I'm generating patches using "git format-patch" so things are number sequenced; other maintainers bundle patches together into large sets (which I don't like, but each to their own). Regardless of the naming convention the build-system applies patches in alphanumeric sequence.
If you intention is to submit the patches to our git repo; be advised that we will not accept/merge them unless we can see the same patches on a kernel and/or u-boot mailing list with acks from maintainers, i.e. we will accept a backport of an upstream accepted patch, we will not accept an orphan patch that only exists in LE (else we will never get to drop the patch in a future kernel/u-boot bump).
-
a) Patch upstream kernel sources to include the dts and build the dtb
b) Patch upstream u-boot sources in include the dts with a u-boot config file
c) Generate patches for the kernel and u-boot changes; ensure those patches apply on-top of existing LE package patches
d) Add patches to the 'patches' folders of either the packages or under projects/Rockchip/devices/RK3399/patches/(linux|u-boot)
e) Modify scripts/uboot_helper to add a device using the kernel dtb and u-boot config file
f) Build the image
There aren't really instructions for this anywhere; GitHub commits serve as 'prior art' and there's a deliberate low-bar requirement for some initiative and general understanding of how distro image building and build-systems work.
-
There is no recovery script; it should prompt the box to re-read the u-boot scripts (s905_autoscript etc.) which will load the LE kernel file and dtb into memory and boot them. I'd need to see UART (serial console) output to understand where it goes wrong - it's always worked for me and others in the past. WeTek did ship UART cables with the box but I'd expect most folks to have chucked it out by now? - The wetek-play2 image boots the device from SD card using upstream u-boot; but only if the eMMC has been erased (removing vendor u-boot) first, and the best way to do that is booting the device from the box image (catch 22).
-
Hard to say without seeing a proper debug log file, but the reason why we have written "DO NOT UPDATE, CLEAN INSTALL" all over the LE10 release notes is that add-ons cause issues due to the Python 2 to 3 changes. If you're comfortable at the command-line I'd stop Kodi and rename /storage/.kodi to /storage/.kodi-old and then restart Kodi. You now have clean instance and can clean install add-ons so they work and stop/move-stuff/restart bits of Kodi content to manually restore the essentials like thumbs, sources, databases, add-on settings, etc.
-
You'd have to track Kodi development to spot the schema changes that result in DB 'version' bumps. If you're using MariaDB the DB versions are now different for K19 and K20 but that only results in you having two active DB versions. You will have to scrap content twice (once for each version) and might end up with occasional differences in content due to changes in scrapers outputting different results, but overall things coexist (in ignorance of each other) and the only thing that doesn't work is tracking of watched/play status. I run in the same way due to ongoing testing and do an occasional "marking things watched" run on the K20 database (as K19 is still the family daily-driver where the changes accumulate). However my kids mostly watch the same stuff over and over so I don't make too much effort to keep things in sync as they'll quickly catch up once K20 becomes the main DB.
-
bertiera please run "dmesg | paste" from the box and share the URL generated.
-
The latest iterations of RPi4 board need newer firmware than we ship(ped) some time ago in the LE 9.2.8 image. You either need to run LE10 or venture into experiments with the newer boot files copied to the LE 9.2 image (Start.elf and one other, I forget the name).
Unless you have a really good reason to need LE 9.2, the LE10 codebase is some way ahead and should be used.
-
Nothing has ever beaten the 85ºC that one of my mk1 AppleTV boxes once reached
-
OSMC spent quite a bit of time fixing issues with 3D support in the Amlogic 3.14 vendor kernel but it was never quite as polished as the legacy Raspberry Pi codebase. I've no idea what state it's in with anyone else's patches and code, but I'd suggest you keep an RPi3 around for that duty when you need it.
-
Enable Advanced or Expert mode.
-
Forcing the SSH daemon to start requires "ssh" in boot params not "SSH" .. the other one that's useful is "textmode" which will boot direct to a text console on-screen instead of Kodi allowing you to poke around in networking, dmesg, etc.
-
I've moved the Python 3.8 images to https://chewitt.libreelec.tv/testing/python-3.8/ .. I don't plan on maintaining them separately but they can hang around for a while. From today the images in https://chewitt.libreelec.tv/testing/ are bug-compatible with LE master again.
-
I've been ripping CDs, SACDs and audio DVDs for ~20 years and have accumulated a size of collection that means a) backups are impractical so I need to consider redundancy instead, and b) the "cost" in time/effort to re-rip everything in the event of a disaster would be greater than the extra $$ for the (currently, 6x 8TB) box. Different people assign different values to their personal time and their collections.
-
-
-----------------------------------------------
LibreELEC:~ # cd storage
-sh: cd: can't cd to storage: No such file or directory
-----------------------------------------------
The shell starts in /storage and there is no "storage" folder there (would be /storage/storage) so the error message being shown is correct and the sources file is still in /storage/.kodi/userdata/sources.xml .. so "cd .kodi/userdata/" or just open nano with the full path.