Posts by chewitt

  • Audio dropouts when using onboard SPDIF

    nVidia cards cannot output 23.976 correctly, it's normally something close, but never close enough for glitch free playback so you will see "pullup correction" to keep things in sync. The debug log shows this:

    INFO: ID:0x1ce Name:1920x1080 Refresh:23.970909 Width:1920 Height:1080

    The only way to resolve this is to use a custom /storage/.config/xorg.conf that details the exact mode timings for the screen, e.g. for my Samsung TV at home I am using this file: aTAB .. the key line is:

    ModeLine "1920x1080_23.976" 74.1756 1920 2558 2602 2750 1080 1084 1089 1125 +hsync +vsync

    the 74.1756 value is a "tuned" version (4 decimal places) where normally it would be 74.17 (2 decimal places) and the extra resolution allows me to reach an actual refresh rate of:

    INFO: ID:0x284 Name:1920x1080 Refresh:23.976080 Width:1920 Height:1080

    Which is close enough that you only see the correction maybe once every 3+ hours, i.e. not during a normal movie. The fun part for you is figuring out the modelines for your TV, as they are TV specific and you can't just copy them from my file.

  • tethering issue

    I'm unable to see the issue, and this reply is sent from a laptop connected to the tethered AP created on an LE box (next Alpha release) so there is no underlying issue with connman. The only thing that might have changed from OE days is the wireless driver, but at that level in the stack the drivers are responsible for the AP feature working or not working (not even being possible) not some 50/50 state.

    If you want a wireless bridge it's time to go buy some proper kit.

  • Enable SSH setting

    Although they may claim otherwise, the other user activated SSH during install which hardcodes it into syslinux.conf and this disables the normal on/off capability in the first-run wizard and settings add-on. From the next alpha build (7.90.008) the ability to force SSH has been removed as part of a general cleanup of the installer.

    NB: If it is forced on, one reason for not being able to connect is an old (out of date) PuTTY version which is trying to use cipher suites that we no longer support in the SSL versions we use.

  • Other services: OpenHab

    GitHub - LibreELEC/LibreELEC.tv: Just enough OS for KODI <= our collection of prior art

    Add-on development is one of those things where the chances of success are proportional to the amount of help you need to ask for. The build system has a ton of existing packages. It's probably missing a few things needed for OpenHAB to work, but the structured format for a package is documented in packages/addons and that's really all the help we can offer - unless you have specific Q's about compiling/linking.

    The lack of documentation is partly deliberate as it acts as a noise filter. My 5+ years experience with LE/OE shows developers who will succeed at the task might ask for a few pointers but existing content is all they need to create something. The developers who seek tutorials and how-to guides are missing the skills to succeed and usually end up asking us to write things for them, which we're not really staffed for.

  • Access Point Question

    It's best to understand that you're using a tethered hotspot (as you'd find in a mobile phone) not an access point; it works as-is and there is no option to reconfigure anything, i.e. make it work like a wireless bridge. That said, devices on the WLAN segment should be able to access services on the Ethernet segment of the network by IP address without issues, but you probably don't have local 'name' resolution which would requires broadcast traffic to be routed over all subnets. As the WLAN segment is behind NAT you'll need to create static routes to have anything on the LAN side contact WLAN devices. If you want anything more than how it is, it's time to $pend and get a proper access point (or bridge).

  • Auto-play video files from USB drive upon insertion

    The correct approach will be to create a udev rule that triggers a bash or python script when removable media is mounted. The script needs to scan the device for playable files and create a Kodi playlist in .xsp format. You can then run a kodi-send "PlayMedia" command to instruct Kodi to play the playlist found at /path/to/playlist.xsp, and then when finished you can use kodi-send "ClearPlaylist" to remove it from Kodi.

  • LCDproc problem

    The add-on for 8.0 builds should appear in the repo soon. It's probably not perfect as-is, but as long as people intelligently report issues we (mostly Anton) will figure things out and push updates quickly.

  • It is normal? USB-DVB

    This sounds like a timing/sequencing issue. Set a 20 second "wait for network" (which should be renamed someday) startup delay on Kodi and then see if the cards have loaded drivers etc. before Kodi (and thus TVH) starts. If that works you can tweak the delay value down.

  • mySQL DB

    It's technically possible but not going to happen in core images. You can use @vpeter's LAMP add-on which includes MySQL (or MariaDB, I forget which) server, or on most LE images you can install the docker add-on and deploy a MySQL container.

  • Botnets and LibreELEC

    1. The packaging of LE/OE ultimately prevents this issue being solved. The OS password file is inside a read-only compressed file. If you can figure out how to write to things inside the read-only file, we welcome the PR on GitHub. The compromise to minimise attack surface (in the context of 99%+ installs being domestic behind router NAT/firewall and without IP/port forwarding) is that SSH access is off by default. We also advise users NOT to expose LE directly to the internet.

    2. In LE/OE a malicious add-on has root access to the OS and can do what it likes. This is partly a failing of Kodi (no sandbox) and partly a failing of LE (where everything runs as root). Neither situation is likely to change in the medium-term and if you have root/admin access to any OS (Win, Mac, Linux, even ye olde OS/2 warp) there are enough binary OS tools for any competent attacker to wreak havoc; we are not unique. There are current examples of add-ons that maliciously attack other add-ons (pirate stream repo's trying to break their competitors). There are also examples of add-ons that take content from the local system and upload it to torrent networks without asking. I am not personally aware of examples of anything that co-opts the box into a botnet, but it is technically possible; hence Kodi Krypton has a new feature to auto-block the installation of add-ons from zip files (which is how you install pirate repo installers which host dubious add-ons) unless you opt-out. In the long-term there are thoughts on how to sandbox things, but that's a complex discussion. TL/DR; be careful what you install and where you install it from, same as every other OS.

    3. As per #1, keep SSH off unless it's being used, use key-auth not password auth, and do not expose/connect the box directly to the Internet.

    NB: Shodan searches reveal a small number of fcukwits who have exposed the SMB or UPnP shares of their LE/OE boxes to the Internet. It's hard to say how that correlates to the number of SSH exposed systems there are without actually self-scanning for them (and I'm not Brian Krebs) but from the number of SMB systems I believe the number is not statistically significant enough to represent a worthwhile/economic opportunity for the actors who perpetrate these attacks; they are normally looking for "low hanging fruit" that provide much larger device counts. This is obscurity not security but it still counts, sort of. On the positive, I have been periodically checking the LE/OE system count via Shodan for some time and the number has not grown proportionally with the size of either project's installed base. I can also assure you that both LE and Kodi teams take security and privacy seriously; both teams have vocal people with professional security credentials on their staff.