If you have fixes for anything please upstream them to the kernel, or at least as far as @Kwiboo's repo where things can be validated and aggregated with other changes we accumulate and prove over time.
Posts by chewitt
-
-
Kodi forums would be the best place to ask for skin development advice; it's where all the skin designers hang out.
-
-
As long as the wireless chips use the standard (correct) device ID's it shouldn't be an issue as the mainline kernel has reasonably intelligent sourcing of the firmware and nvram files (detecting the ID's and using a lookup table). Current VIM1 does not use the correct ID so once we start condensing images we'll need to hack a solution together (and it being hacky, it probably won't be upstreamable) .. but I have some ideas.
-
I'm not aware of any skins supporting custom_ prefixes, but then I don't follow skin development so it might be possible. However, you need to clone and then rename the skin, e.g. create mimic-mod, else any updates to mimic will overwrite your changes. Since you now have a custom skin, it would be easier to edit the normal .xml file. You will need to reload the skin (via kodi-send commands) or restart Kodi to see any changes.
-
Anything involving Ace streams is piracy and falls on the wrong side of forum rules.
-
I'm also out of town .. the longer log (via the settings addon so it also contains systemd journal) after 10 mins would be useful. I don't see these issues with my 918+ so there's no known issue with Synology kit.
-
If should be possible to create an LE 9.0 image but in addition to changing the legacy driver to the last 304.xx version you'll also need to change to an older Xorg and maybe mesa packge else the driver doesn't support the minimum ABI version required. IMHO it would be easier to start from 9.0 and revert a small number of things to support the older driver, than start from 8.2 and figure out the larger number of things needed to sustain newer Kodi.
-
I'm not sure where "script.libreelec.devupdater" came from, but it's not our code, so not our responsibility to fix. Please nag the creator
-
If you image a working SD card you are creating a file that matches the 16GB? of the card, even if the card only has 1GB of actual data on it. It would be faster to create a backup (in LE settings) that you restore after installing the default LE image, as this will only be the actual data. The difference in time is simply the difference in how long it takes to write 1GB vs 16GB (or whatever capacity the SD card is).
-
Make sure the hotspot is running on channels 1-11 else (without configuration to set wireless regulatory domain) it won't be able to see 12-14.
-
Did not test long enough to invoke/notice Graphics Crash or perhaps crash is less frequent now?
There are still some unresolved memleak issues but overall stability in mesa code has improved after the latest round of bugfixes.
-
Do you know if the 3.xx kernel based distros have the Wifi driver included for the SV6051P WiFi chipset, including the softAP function?
This is a popular chipset with X96mini, Mxqpro and A95X etc but unluckily the vendor seems to have gone out of business and I am told the SV6051P driver is not compatible with the 4.xx kernel.
My problem is that my X96mini 1/8GB S905W box works fine with SV6051P WiFi , but for some reason I cannot set up the WiFi AP tethered hotspot mode in LE Configuration ( I can click on buttons but the SSID is not showing up in either my phone WiFi settings or on the WiFi Analyzer app.)
It's included in the older kernels but the wireless hotspot function requires drivers to support it and many of the 'Android' drivers do not. We made an attempt to port the SSV6051P driver to the mainline kernel but it needs more than a little tweaking (it's the worst piece of driver crap we've seen in a while) and the attempt was eventually abandoned. My honest advice to anyone seeing a universal solution for hotspots and/or providing support to boxes that have problem wireless chips is to pick up a used 'compact' wireless router (my personal favourites are Apple A1rport Express devices) and use it as a simple Ethernet bridge. It will give better wireless performance and is often cheaper than a decent USB wireless dongle (which inevitably ships with realtek drivers that we may/may-not support) and you avoid all future issues with drivers.
-
You can make a feature request in the Kodi forums. It's not something we can do without Kodi support.
-
I'm not aware of another repo. The best I can suggest is having a look at my old LE 7.0 branch for AppleTV which is here:
Comparing LibreELEC:libreelec-7.0...chewitt:appletv-7.0 · LibreELEC/LibreELEC.tv · GitHub
If you look at the core changes made to re-add i386 support to the build system, the basic process will be the same, then it's trial and error to find all the packages that are x86_64 only and re-add support for i386.
-
Kodi does not transcode, so no.
-
Create a USB using LibreELEC-Generic_x86_64-9.0.0.img.gz and then boot it with a USB keyboard connected. At the syslinux prompt hit any key and it stops boot. Instead of running the installer (the default option) use/type "run" mode and it should boot into LE from the USB. Enable SSH or use the local console on CTRL+ALT+F3 to mount the boot (first) partition on the internal drive and delete the boot files, then copy the contents of /flash over to replace and update the boot files. Reboot without the USB bits connected and it should now boot into LE. You be glad to know that LE added a check in the update process (about 2.5 years ago) that will abort the update when the image filename doesn't match LibreELEC-Generic_x86_64-<version> so it will take deliberate ignorance to repeat the mistake.
NB: OE installs often have a lot of crap still installed due to some dubious packaging decisions in the 8.x image. You might want to consider backing up the essential files and then doing a clean install and manual restore to effect a spot of spring cleaning.
-
Ooo.. nice work!
