Posts by chewitt

v7.90.003 (due soon) will revert from KMS drivers to Intel drivers to solve a range of graphical glitches and issues on Intel cards. No guarantee that this is one of them, but I would ask you wait and test when it's released. You can also test with a current Milhouse build which includes the same changes.

Sounds odd. Try the current Alpha builds or a current Milhouse build (from Kodi forums).

cp /usr/lib/udev/rules.d/95-udevil-mount.rules /storage/.config/udev.rules.d/95-udevil-mount.rules
nano /storage/.config/udev.rules.d/95-udevil-mount.rules

append the partition names you do not want mounted to the list, see udevil: prevent noobs partitions from auto-mounting by chewitt · Pull Request #386 · LibreELEC/LibreELEC.tv · GitHub and reboot. The new modified file will be used instead of the embedded one. If you have not named the partitions, name them.

The text on that page probably needs to be tweaked. The intention in the original statement (which I wrote) was more about being communicative and responsive to questions on schedule; which I hope we're being. Advance publishing a schedule with dates will be a challenge as we're dependent upon upstream Kodi which is proving to be a fluid target. That said, maintenance releases for 7.0.x have settled into a ~4 week-ish cycle and the Alpha builds were looking like a ~2 week-ish cycle but we delayed v7.90.003 to wait for Kodi A2, it should be out soon-ish. By the time we reach Krypton release (current guesstimate is late August or September) learning will be done and we'll better understand what we can committ to, and how to word it

cp /etc/X11/xorg-nvidia.conf /storage/.config/xorg.conf
wget http://sprunge.us/PJCF -O xorg.log
nvidia-xconfig --extract-edids-from-file=xorg.log --extract-edids-output-file=/storage/.config/edid.bin
nano /storage/.config/xorg.conf
(uncomment the 3-4 lines related to edid.bin then save)
reboot

that should do it. The device is DFP-0 which is the default config in the xorg.conf file so no need to change values.

cat /var/log/Xorg.0.log | paste

run that after a clean boot, share the URL it generates here

Krypton is already quite stable for pi devices. Not perfect, but should be enough to pass a WAF test.

There are some changes to BT pairing in the 8.0 settings add-on that are probably the reason it works on the alpha build. BT audio isn't widely used and development moved to 8.0 so there are no current plans to backport the changes.

Kodi generally doesn't save settings until you shut it down. In Jarvis the save process is also subject to issues with add-ons that keep Kodi running for longer than other processes expect it to have stopped during OS shutdown/reboot; if the save ends up incomplete then on restart the XML is broken and Kodi reverts to a clean state with all settings lost. So far little has changed in Krypton. If something works/worked okay with Kodi on another OS this is the result of luck not design because the root cause is internal to Kodi itself. We are also seeing issue reports with backups that suffer similar issues. In the case of backups we are considering changing our backup process to be reboot-based to ensure Kodi is not open (and thus settings have been saved, and DB's are static) to ensure backups are good. The general issue needs to be raised further with Kodi developers; the trick being to find ears who are sypathetic to the issue and interested in coding the changes.

LE v7.0.x and OE 6.95.x have diverged in how the OS is built (OE's creator decided to rework half of the build-system in the week before releasing his beta) but the end result is largely the same; no major differences.

I'd like to see us extend the capabilities of the LE settings addon to include more pi config things. The need for overclock settings has died out now that pi2 and pi3 have more RAM and higher clock speeds, but things like codec licenses and some other basics should be possible. @gda is correct stating that these are things you only need to set once in the life of a pi, but as pi devices represent ~65% of our userbase I think we can do more.

NB: A RasPlex style installer is already being worked on. We've used their code as the base and improved it a little .. but this won't help you configure a pi because the installer only downloads the image and writes the SD card. There are not config tools in it.

FYI, one of the primary reasons we forked from OE was stability. The guy that runs/ran OE felt it was acceptable to add 300+ untested commits (mostly package bumps) to the project codebase 24 hours before releasing a major beta. He did that kind of thing regularly. He did that kind of thing even when we expressly asked (and then begged) him not to. It pissed off a large number of people in and around the project. If OE was stable for individuals like yourself it was the result of luck more than design, because he was gambling with code.

Your experience is not normal and bad performance is usually the result of bad hardware (e.g. dying SD cards or shitty network devices) or plugins (esp. the less than legal ones out there). As Klojum has said, a Kodi debug log is the best way to start.

The hidden files option in Kodi GUI works only on Kodi GUI, it has nothing to do with Samba sharing.

#1: In my experience there is ION, and then there are all the nVidia boards that people call ION that are actually something else. Tell us the actual nVidia GPU number by running "lspci" and we can confirm whether the board is supported or not.

#2: It is possible to capture the EDID from the TV when it's connected to an edid.bin file and then use a custom xorg.conf that references the edid.bin file to ensure Xorg always thinks the TV is connected. Read: Config EDID nvidia - OpenELEC

#3: Ignore my colleague Klojum, he's confused; config.txt is a pi thing

The answer will depend upon the EPG data source that you're trying to work with?

Nope. That's *exactly* the same as what I gave you, only the extra two lines Milhouse documented also disable Bluetooth.

The LE/OE build-system is relatively simple to figure out (very logical) and full of "prior art" to crib and learn the process of extending the core OS and creating add-ons from. There have never been nicely written guides or tutorials because creating packages/add-ons requires developer skills, and people with the skills to succeed tend to poke about and ask a few specific questions, while those who do not have the skills (self included, I'm no developer) need to ask for tutorials and guides. Unfortunately, to package an entire Linux distro in two files requires greater up-front complexity in the creation process compared to a more conventional distro, and it raises the entry-bar on tinkering.

Anything built for a recent version of OE should work on LE. I'd try installing Chemstars add-on first before reinventing the wheel.