Posts by chewitt

LE 10.0 will drop Xorg support in favour of DRM/GBM which allows us to support 10+ SoC/GPU types with a single/common driver framework. The notable exception is nVidia who chose to implement their own EGL streams 'standard' which nobody else uses. There is currently very low desire among the Kodi developers to implement another proprietary code path in Kodi just for nVidia, and the current VDPAU code path is no longer developed (no 4k, no 10-bit) so there is is a genuine possibility that we stop supporting nVidia GPUs in the future. LE 9.0 will include some additional stats reporting on GPU types to help us evaluate that decision.

TL/DR .. it's probably best to avoid putting nVidia cards on your shopping list.

/storage/.config/autostart.sh can script/apply changes at boot time

As I currently understand it (caution: I am not a developer) Kodi outputs progressive so the whitelist only shows progressive modes. If media uses an interlaced format Kodi shaders are used to deinterlace and render as progressive.

TinkerBoard S and non-S are close enough in spec that we should be able to provide a single image for both. Current focus is on getting the core features like audio/video working properly so there hasn't been much attention on installation packaging beyond ensuring test images boot from an SD card. RK support is progressing but things are still in early stages.

The LE settings add-on is not integrated into Kodi (only a shortcut in the skin) so it has no ability to natively access SMB share "sources" that you configured in Kodi, e.g. that are visible to the native FileManager. It only supports backup and restore from "local" storage, so removable USB/SD devices or a remote SMB share that has been mounted to a location in the local filesystem. If this is important to you, have a look at the example mount files for smb in /storage/.config/system.d/

There's nothing to do as the "ALSA: AML-M8AUDIO, HDMI" device outputs simultaneously on HDMI and S/PDIF .. I used it that way for a couple of years before finally upgrading my AVR to something that supports HDMI audio input.

Boot up another Linux distro and connect the drive bay and copy files. If you see similar issues it's likely a problem with the drive bay. If you don't see the same problems it's something freaky with LE, but the challenge will be identifying what. Unless there are error messages in dmesg that correspond to the corruptions there is really nothing to go on, and this is the first time I hear of something like this.

Pi hardware supports OMX and MMAL decoders. MMAL should give best results, but requires more processing grunt. At some point the default in Kodi was changed to MMAL, so I have a hunch the difference between installing 7.95.3 and later releases is that the older install has OMX as the default and this preference is retained through upgrades. Later installs (dictated by hardware support) default to MMAL.

Pi v1 hardware probably doesn't work great with MMAL due to the higher overheads whereas the 3B+ will be fine with them. You can change the decoder to experiment in Kodi player settings (needs advanced or expert mode).

If you know autosubs is causing the problem; report that to the author(s) of autosubs via the Kodi forum.

Raspberry Pi has a tightly integrated kernel and decoding stack that are attentively maintained by the Pi foundation developers because over time good Kodi support has helped them sell lots of boards which means more $$ for their charity work. On the other side you have a festering turd of an Amlogic board-support kernel supporting the manufacturers limited range of Android test cases that has been repeatedly "fixed" over a long time period by inexperienced community developers who lack the experience to architect and author good code. On the Kodi side this is partnered with a vendor-proprietary code interface (amcodec) that was originally created by the same team who made a mucking fess of the kernel code and has since been repeatedly "fixed" by the same community developers who lacked the low-levels skills to fix things correctly in the kernel. It has seen some cleanup in the last couple of years but hacking Kodi to workaround deficiencies in the kernel is the long-term unsustainable trend.

TL/DR; RPi runs great code but lacks the grunt for 10-bit content. S912 devices have the grunt but are forced to run lower quality code. Both run Kodi the app, but internally they use different and not equal code paths.

We have now removed moonlight from the LE9.0 add-on repo due to it being highly fragile and nobody on staff having the hardware to test it. We left the removal PR open for ~2 months hoping that a passionate user in the community would step-up and volunteer to maintain it, but nobody did, and we dropped the code a couple of weeks ago.

I cannot recommend brand/model of cards but if you find hardware that uses Atheros chips using the ath9k driver and it will be reliable; the driver is well featured and well supported within the kernel.

It about design philosophy. If you want a Linux distro with console install package management there are many to choose from. LE has the goal of being a GUI oriented 'appliance' and in the projects ~10 year history it has not needed or wanted a package manager. I'd be more interested in knowing what the 3-5 legitimate (not piracy or content stealing) binary applications are that people want to install via a package manager so those can either be embraced in the core distro or be adapted to GUI installed add-ons (or added to existing tools add-ons).

Country in Kodi has nothing to do with wireless regdomain. This is set by the kernel (or forced through kernel module 'options' settings via a conf file when associating to a network. For pi it's something we have wanted to expose in the LE settings addon for a while as channels 12-14 are not scanned-for unless you force the regdomain setting. Country in Kodi is used for clock offset from UTC only.

Updated addons need to be built and pushed to the repo. It will happen over the next couple of days, probably.

To rule out a playback issue vs file corruption create an MD5 hack of the file on Windows and on LE, then compare. If the hashes are different the file on LE is not the same as the file on Windows. If the hashes are the same the file is not corrupt and it's a playback problem.

Realtek provide badly written drivers that don't follow kernel design or quality standards that are never submitted (upstreamed) to the Linux kernel so they are a pain in the rear to sustain over a long period of time. As a result we ran out of enthusiasm for adding more of their crap to our distro several years ago, but if users submit working driver packages to our git repo along with a commitment to maintain the driver for the foreseeable future they will be considered.

Nobody on staff touched the 8.2 branch in a while (months) so I don't think anyone will be volunteering to bump addons there now.