It would be useful to see the system (not Kodi) log when the USB device is attached. And yes "it's only a USB stick" but what is the PSU rated for? .. bad behaviour during boot and device attachment is a common symptom of unstable power.
Posts by chewitt
-
-
Nothing stands out in the log, although it's not a debug log so it's harder to guess what Kodi internals might be doing. It's normal for things in databases and caches to be reprocessed and validated though, and in the background Kodi downloaded new versions of add-ons too, which included services like Tvheadend. Give it an hour and see if the dust settles.
-
Changes in https://chewitt.libreelec.tv/testing/LibreE….arm-12.0.0.tar might do the trick then. If yes, I must nag Kwiboo about upstreaming that patch
-
It can be changed though, fortunately..
-
Once Kodi figures out how it wants to output it requests alsa channel maps and then walks the list to find a match. List ordering is involved here so _marklam_ please update to https://chewitt.libreelec.tv/testing/LibreE….arm-12.0.0.tar and see if anything changes for you. It's the LE12 release with some personal cosmetic changes and https://github.com/chewitt/linux/…95c6bb50b5431c3 applied to the kernel. I don't think it will make a difference, but you never know.
-
popcornmix any ideas?
-
The AVR advertises BL/BR and BLOC/BROC over HDMI. ALSA refers to BLOC/BROC as RLC/RRC but the media being played uses a normal 7.1 layout with SL/SR side speakers which alsa matches to SL/SR using: https://github.com/xbmc/xbmc/blob…A.cpp#L288-L289.
If the widest rear speakers are denoted as BL/BR i'd argue that Kodi is doing the right thing when it sees BL/BR with an exact match and then maps the inner rears as a virtual RC channel resulting in a 6.1 layout. It doesn't make sense to me to use inner-rears as BL/BR and the outer-rears as SL/SR. If that's the result you're looking for; reconfigure the positions in the AVR or rewire the speakers to be SL/BL/BR/SR then the ELD presentation should reflect that and Kodi should give you that.
-
Generic (GBM) supports HDR, does not support Chrome. Generic-Legacy (X11) does not support HDR, has Chrome. It's possible to install Transmission but we do not provide piracy tools from any of our repos, so figuring that our is on you - and be mindful of our forum rules if you want support.
-
Buffer settings typically cause more problems than they solve and most tweaking articles are written by people with no clue how the underlying code actually works (and has changed in recent times). In short: if your network works, you have no need to tweak buffer settings. If your network doesn't work, fix your network. NB: Long Ethernet cables might not be desirable for normal use but can help triage the problem, i.e. if the problem goes away on Ethernet, the problem is that WiFi is often rubbish, and the solution is to (again) fix the network.
-
LE injects/adds some additional bits into the boot flow but if those files are not found the box should default to Android. If you've used "install2internal" then you may have removed/overwritten some of the Android partitions. Amlogic (Android) ".img" files are normally for use with Amlogic Burning Tool and the USB OTG port not the Android on-box/OTA recovery process, so I'd try flashing with that first. Google will find you a few thousand HOWTO articles and the binaries if you're not familiar with it - it's not really an LE topic we handle. Forums like 4pda are probably more helpful.
-
Starting over should not be needed, but when faced with a weird/old TV that's not playing ball and someone with a much upgraded config (and thus likely hoarding unknown bits of old config) .. a clean install eliminates some guesswork and reduces the number of variables involved.
RPi boots using code (that cannot be changed) in the chip. This boots firmware on the SD card which reads EDID data from HDMI, which boots Linux, which reads EDID data from HDMI, which boots Kodi, which reads EDID data from HDMI.
RPi boots from an SD card. So just use a different card to test with LE12 and then the existing setup isn't touched. You don't need a Linux machine to create a bootable SD card (even lowly Windows can manage it, and we have an app to make it simple).
-
Unless it has an nVidia GPU (which is unlikely, Chromeboxes are normally Intel) .. use normal (non-legacy) Generic.
-
Do you think I'm right in believing that an external dongle using an RTL8188 chip should be supported?
It's not the fastest chip, but for connectivity and fiddling it should work fine.
I can't explain the need to connect HDMI after boot. It's not something I've seen with any of my own test devices.
For kicks, update to https://chewitt.libreelec.tv/testing/LibreE…ch64-12.0.0.tar. It's unlikely to change anything but you never know what magic newer kernels and such might bring.
The remote can be gotten working with: https://wiki.libreelec.tv/configuration/…ration-advanced
-
Will be posible to do the same command in Liberelec linux? or automatic clean up in the next reboot?
In short, no, because the tool to do that, i.e. fsck.ntfs doesn't exist.
-
Spaces are legal but will need to be correctly quoted everywhere else things break. If you want an easier life, avoid naming devices and shares with spaces.
-
Not planned. LE is a deliberately simple media client/player OS for Kodi, not a general purpose distro.
If you want to run other apps, we support Docker or Podman containers.
If you want to run other OS, use a general purpose distro like Ubuntu not LE.
-
i noticed that 12.0.0 is out on git as a new branch.
LE 12.0.0 is tagged but there is no "libreelec-12.0" release branch yet (so we can still change/retag things if needed).
The two main rules to avoid git conflict problems are:
a) Fork our repo to your own GitHub account then clone from your repo (not ours).
b) Always work in a topic branch, never work in the master branch.
If you cloned our sources directly from our repo you can always fork it online then reset/change the 'origin' location in your local clone of the repo to be your fork (edit .git/config and change the URL). If you are working in the master branch you can simply checkout a new 'mychanges' branch from master, then you can add an 'upstream' remote, pull changes from upstream/master and then hard reset your local master branch to match upstream/master. Your local changes are still be in the 'mychanges' branch and now you can rebase against the (updated) local master branch before rebuilding an updated image. The process might initially sound complicated and there's some terminology to become familiar with, but it's just a new finger-habit to learn.
Have a read here: https://wiki.libreelec.tv/development/git-tutorial
-
If you ask or solicit opinions you will find a huge number of people who want it, a moderate number who offer to be "testers" for it, and nobody who's prepared to roll up their sleeves and do the actual work. Features like a browser are not wished into existence.
