Posts by chewitt

    If the drive will only be used with LibreELEC you can format as EXT3 or EXT4 and the filesystem drivers run in the kernel. If you need the drive to be compatible with macOS or Windows you need to use exFAT or NTFS and the filesystem drivers run in userspace which is considerably slower than running in-kernel. You can have compatibility *or* speed, not compatibility *and* speed.

    dmesg shows 2x SATA controllers with 2x 6.0 Gb/sec and 1x 1.5Gb/sec channels in use with a 120GB (Sandisk SSD) as /dev/sda and 2.0TB (Seagate) drive as /dev/sdb and a BD player for optical media. The 2TB drive has some GPT partition header problems and Linux tends to err on the side of caution to avoid further damage to the filesystem; there's no log messages to suggest it mounted. Log entries are adjacent to some USB related messages but none of your drives show as connected to the USB bus.

    Code
    [    3.158910] GPT:Primary header thinks Alt. header is not at the end of the disk.
    [    3.158914] GPT:3907029163 != 3907029167
    [    3.158916] GPT:Alternate GPT header not at the end of the disk.
    [    3.158918] GPT:3907029163 != 3907029167
    [    3.158919] GPT: Use GNU Parted to correct GPT errors.

    ^ fix the problem and the 2TB drive will mount.

    Over time we've seen an increase in TV screens which are capable of displaying things the HTPC device can't handle, but all Kodi sees is the list of resolutions from EDID on the HDMI connection, so it's become necessary to provide some better controls for how Kodi handles resolutions and refresh rates. Settings > System > Video > Whitelist; contains the whitelist of resolutions and refresh rates you need. If there are no entries Kodi will remain on ~1080p60 which is the default.

    Did you go through the process of whitelisting refresh rates (else Kodi will play everything at 60Hz)? .. and since it's an nVidia card the OOB modelines are not particularly accurate and it's possible to use a manual xorg.conf and tweak them to be more accurate.

    The backup file is a standard .tar archive so it's nothing special and if required you can unpack it on the network share (whether Linux NAS or a Window box) and manually move files back over. The restore process is nothing magic, it's basically just stopping Kodi, removing 'new' folders that are auto-created on install, then moving old files/folder back to the right locations and then restarting Kodi again.

    Have you tested with a mainline kernel? Nothing found — Yandex.Disk contains Armbian images for GXM using 4.18 which would be easier to work with for development and tinkering purposes. If you're capable of writing network drivers the lack of device-tree for the T95Z shouldn't faze you too much.

    RK kernel team don't have much documentation on that chip; mostly a comment that it's compatible with the RTL8211F part so the only difference might be power or a crystal oscillator. I didn't hear back from AML team.

    It's not impossible or particularly difficult, but we already have 4-5 different collections of brmfmac firmware and instead of tacking another on to the build system for the Generic x86_64 image it's about time we consolidated them and came up with a sensible build-time and userspace method for supporting device/board specific nvram configs; because we currently assume devices that use the same brcmfmac chip can use the same nvrman config and that's not the case (and I suspect this is why we have accumulated multiple firmware collections over time). That work gets a little easier once we have more devices on a common Linux 4.18/4.19 kernel codebase (as the kernel-firmware repo provides the latest or common firmware, but no nvram configs) so I wasn't planning to look at it until after LE9.0. If will probably be done for LE9.2 once we start to shift some of our Android-oriented hardware groups off legacy BSP kernels, which is always a good time for package spring cleaning.

    NB: in the Bluez move from hciattach to btattach the codebase is still fresh and I already found a number of cases where brcmfmac device ID's aren't mapped so devices either don't prompt for firmware or the filenames (as documented in all the howto guides you find in Google) need to be adjusted.

    In summary.. if you have a homebrew solution that's working please stick with it for a while, and we'll catch you up sometime later in the year.

    If you want it use SMB1 set Kodi smbclient version min/max to SMB1 so it cannot connect using SMB2 or higher, because the default protocol version is SMB2 or SMB3 (I forget which) and if enabled, it will connect and fail, there is no dynamic step-down to SMB1. Yes this is complicated. No it's not our fault. Either way, the sooner you start using authenticated connections the sooner you won't have to reconfigure Kodi again once some other MS change is pushed down.

    1. Yes, assuming you have an IR sensor that the Harmony can be programmed for. If not, get a 'flirc' receiver.

    2. There are ways but we avoid discussing how to bypass geoblocking in this forum because basically it's a form of piracy

    3. Sure (did you Google?) but beware of piracy laden crapware repos, not good for boxes and we'll refuse all support if you install them.

    4. Go back to Windows, it won't run under LE

    5. Yes, but it will require the current LE alpha release and one of the Netflix addons from the Kodinerds repo