Err, my bad .. MT7601U .. I updated the URL in the above post. Those folders are overlayed on /lib/firmware at boot time so that firmware appears in the correct location.
Posts by chewitt
-
-
Sources are in /storage/.kodi/userdata/sources.xml .. so SSH into the box and use the nano text editor to edit the file, the format is quite simple to work with and I find some copy/paste in nano is much easier than using a remote to set host/share info in the GUI.
-
Current plan for WeTek Core support is to find one on eBay somewhere in the EU and ship it to Martin. I also have a box, but 3.10 device trees are so radically different from what I'm used to (device tree was a very new invention back then) that I honestly don't quite know where to start

-
Code
mkdir -p /storage/.config/firmware/mediatek cd /storage/.config/firmware/mediatek wget https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/plain/mediatek/mt7601u.bin reboot^ SSH in and run these commands. The kernel has the MT6701U driver enabled but it complains about firmware. The error reads like it's complaining about the wrong firmware, however I can't see any sources for the firmware included in the RPi2 image so I have a hunch it's a badly written error and it's complaining about no firmware. Running the above commands should add it to an overlay folder so (on reboot) it appears to be in the right location for the driver to find it. No harm in trying..
-
The fix commit is in Linux 5.10.0 which means LE10 images (e.g. current nightlies) already have it included. There are currently no plans to make another LE9.2 release, but if that should change I've added it to a list of things that might need fixes backporting.
-
Since a while now Kodi defaults to SMBv2 which means Kodi on Linux does not support "browsing" and you must manually create a source using fixed host and path information. Kodi on Windows is different so any comparison is irrelevant.
-
new wiki creator says "about time someone other than him learned to do stuff in the new wiki"
documentation/.gitbook.yaml at master · LibreELEC/documentation · GitHub
^ stuff can be added there
-
-
Software problem.
-
-
Create the image. Boot the image. Enable SSH, and /flash will exist (it won't be writeable unlesss you remount as read-write). Or create the image and connect to any OS and the files are in the boot partttion where you can edit them. I'm not sure what you did, but it sounds like over-thinking things.
-
-
I don't have a "solution" .. but here's some thoughts that might be useful:
GTX260 does not have any on-board audio capabilities; it is normally a DVI output only card and DVI does not carry audio. As this is the era before nVidia figured out how to do HDMI properly the card shipped with a cable that connects the motherboard soundcard digital output (S/PDIF) to unused pins in the DVI connector which a custom nVidia DVI to HDMI adaptor uses to present "HDMI" audio to a TV or AVR. HDMI and S/PDIF send the same signal, so this allows the card to send full 8-channel audio via HDMI (over S/PDIF the bandwidth is reduced and the receiver will not support more than 6-channel, i.e. 5.1 audio). For this to work in Windows an nVidia audio driver must be used .. so likely there is something similar under linux. If you are using DVI not HDMI i'm wondering what might happen if this cable is disconnected and/or any nvidia audio modules are blacklisted to prevent them from being used.
The kodi.log only shows "nVidia" audio devices being presented by ALSA, yet some fiddling with pulse (which reads hardware capabilities from the kernel in addition to being aware of ALSA devices) managed to get some audio out. I suspect via you've managed to route audio to the internal card; either by ignoring the nVidia devices or via snoop/dmix sending data to all devices. When fiddling with the config in alsamixer did you save/store the active configuration? .. this is not automatic.
In the past (when we supported mk1 AppleTV devices which I maintained) the PCM output volume needed to be 100% before S/PDIF output worked; any less and the signal strength wasn't enough to be correctly carried (S/PDIF is digital but the signal still needs to be clean/strong enough for comms to work). The description of audio needing to be zero is the exact opposite, but makes me wonder if anything above zero results in additional audio data being mixed into the audio output and disrupting the digital signal.
-
Currently no 4K and no HDR, the focus is on getting 1080p decoding and seeking working reliably. Both will be added later (no ETA on when, there are a lot of depdencies).
-
-
DDuck007 LibreELEC-Generic.x86_64-9.80.8.img.gz <= see if this image works, it's current LE master with mesa bumped to v20.3.1 which includes the fix that I flagged earlier.
-
It can probably be done, but there's no official interest in doing it as Intel Gen10 GPUs will be supported in LE10 and you can use a nightly image from Index of / to run Kodi (Generic is quite stable).
-
To herd the conversation in a more useful direction, this smells like the same problem Black Screen after Updating - LightDM/Xorg dosnt start / Pacman & Package Upgrade Issues / Arch Linux Forums and this patch may be the fix upgpkg: mesa 20.3.0-3: radeonsi: fix regression on gpus using the rad… · archlinux/svntogit-packages@2a3a08a · GitHub