Posts by chewitt

If you don't care about your problem enough to provide a log file when asked, we don't care enough about your problem either

Some people are stuck in the past and don't realise we abandoned OE in February 2016

No log = no problem in the pre-alpha unreleased software image that you found somewhere on the internet.

If restoring from within LE to a new card you need approx 2.5 times the backup file size in free space to perform the restore; because you have to copy the backup file to /storage first before the settings addon uncompresses the backup file during the restore process, and the OS requires some working buffer space during the archive extraction process. The backup file is just a standard .tar archive so there's no magic involved.

You can expect the occasional screen freeze or things can hang after using PVR functions for a while or when doing large jump backs on a media file as there are known (and not going to be resolved in K17) bugs and the underlying Linux kernel used in the 8.2 release has ugly moments.

The screen turning white with vertical lines and audio pops .. sounds more like a hardware problem. If you also see problems in Android it would point to something. How hot does it run? .. a heatsink is never a bad idea.

Yes/No depending on how you took the backup.

If you backed-up using our backup function you only copied the data within the filesystem (which is less than 16GB, usually not much more than 3-4GB even for a large media collection) so it should be quite simple to restore 3-4GB of data to a 16GB card. If you were inappropriately obsessed with "backing up the whole card" like most Pi users and you image dumped the full 32GB SD card, then no, you cannot restore the 32GB image to the smaller 16GB card without breaking the filesystem. It's still technically possible to break and then repair the filesystem, but that requires expert knowledge of filesystems and some software tools, and you need to hope all the data was within the first 16GB (likely, but not guaranteed).

If making backups, focus on the small amount of data on /storage, not the entire SD card. It's faster and easier to backup the ~4GB of data on the card than the full 16GB or 32GB of SD card which is mostly empty.

We don't so shopping site comparisons of distros. Just go try things and pick the stuff that works for your use case.

Rockchip support is still "work in progress" but hardware video decoding definitely works.

It's a shell script, so it should look like the shell commands that you ran manually, but with /full/paths/to/binaries where used.

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.