Please provide "dmesg | paste" from a clean boot so we can see what the kernel logs.
Posts by chewitt
-
-
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.
-
No news. I'll remind people it's a good idea.. again
-
-
If you labelled your USB stick 'Storage' did you also change the label for the SD card second partition? (which by default is also Storage). If you end up with 2x 'Storage' I'd guess the SD card will be probed for and mounted first.
-
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
-
The one reference to that PHY that I found on Google was on schematics for the Rock64 (a Rockchip device) but marked optional, and TL Lim who makes that board says he has no memory of looking at ZTE parts. I've asked internal to Amlogic as well, but if it's only been used in a handful of devices I wouldn't be too hopeful.
-
-
The normal complaint about slow Ethernet on recent/mainline kernel is solved by disabling eee in device tree or from userspace via ethtool.
See linux/meson-gxbb-odroidc2.dts at master · torvalds/linux · GitHub .. although that dts is for mainline kernel so that binding might not exist in the older BSP kernels.
I can ask contacts, but replies to random Q's (vs. things we're working on) are never quick.
-
-
Android only due to the locked bootloader.
-
An 802.11n device with dual antenna supporting 5GHz modes and a well written driver will outperform the latest 80211.ac hardware with a crap driver. And 802.11n hardware might not make use of the full 802.11ac featureset, but it's fully compatible with 'ac' routers. And if you want your media to play reliably you'll run an Ethernet cable, because ultimately all wireless leads to disappointment

Last time I looked on eBay there were still plenty of 'Virgin' branded WNDA3200 adapters (which use ath9k) going cheap. I bought a couple for £4/each but that was a while ago. Use wikidevi to find other brands/models.
-
3B+ is considerably better than B3 for radio things. The next alpha release will have some BT firmware improvements for the RPi3B+ that reduce interference with wireless (which is usually active at the same time even if you're using Ethernet) which might help.
-