Posts by milhouse

    I would suggest you both contact Realtek and urge them to get their drivers added to the mainline kernel. I want to see less out-of-tree Realtek drivers in LibreELEC (ideally: none) and not more, as they're an absolute nightmare to support, so I don't think the RTL8812BU will be supported any time soon I'm afraid.

    Realtek really do need to get their sh*t together and stop releasing hardware without in-tree kernel support and then leaving it up to the open source community to bail them out by providing drivers of variable quality.

    It's unfortunate that you've already bought the Realtek hardware, with luck maybe you can get a refund and purchase hardware from a vendor (Intel, Broadcom) that has done the right thing and pushed their driver upstream.

    Kernel 4.13.2 currently defaults CIFS mounts to SMB3. You need to add ",vers=2.1" or maybe even ",vers=1.0" as an extra option when connecting to older Samba servers, ie.

    Code
    Options=username=user,password=password.,rw,vers=2.1

    You can see the message in the log explaining why the mount is failing:

    Code
    Sep 17 09:32:24 LibreELEC kernel: No dialect specified on mount. Default has changed to a more secure dialect, SMB3 (vers=3.0), from CIFS (SMB1). To use the less secure SMB1 dialect to access old servers which do not support SMB3 specify vers=1.0 on mount. For somewhat newer servers such as Windows 7 try vers=2.1.

    It's possible that later 4.13.y kernels may switch to SMB2.1 as the default, as SMB3 is not as widespread as originally thought. LibreELEC 8.2 will default CIFS mounts to SMB2.1.

    If the path to the media files isn't in your sources.xml then Kodi won't play it - it's a security feature. So make sure the sources.xml on LibreELEC includes all the same paths (ie. sources) as the sources.xml on the Windows machine you are using to scrape the library.

    Mario77 CIFS (OS) mounts will (in pre-4.13 kernels*) default to SMB1, so yes your SMB1 CIFS mounts will fail when connecting to an 8.1.1 Samba server using the default SMB2 min protocol setting.

    Your options are to enable SMB1 on the LE 8.1.1 Samba server (not a good idea), or add "vers=2.1" (or better) to your CIFS mount service in order to establish an SMB2 (or better) connection, ie.:

    Code
    # Any options you usually use with the "-o" parameter in the mount command
    Options=username=USERNAME,password=PASSWORD,vers=2.1

    Adding "vers=2.1" to the service may already work when connecting to an older LE 8.x or 7.x server, so could be added before any server upgrade.

    We may need to update the sample config/wiki to mention the vers=x.y option.

    * starting with 4.13.0 the kernel will now default to SMB3 when establishing a CIFS mount.

    Potentially, yes. Is the LE or Windows PC connected over wifi? A flakey router or access point could result in lost packets that might confuse Windows. If wifi is involved try testing only with wired connections and see if that is more reliable.

    Not sure, it will be somewhere in the Windows Firewall settings (sorry not a Win 10 user so can't be more helpful than that). It would normally be quite strange for the firewall to block an outbound connection on the local LAN but I've not seen your issue reported before with LibreELEC and Samba4, so can only assume right now that there's a problem with your network (or Windows 10 PC).

    Hi,

    I enabled debug-logging in kodi and I tried to put the brcmfmac-module in debug-mode, providing a file with options brcmfmac debug=0x0003FFFE  in

    Note that CONFIG_BRCMDBG is not currently enabled. I will enable it in my nightly test builds (starting tonight, with #0906).

    If you wish to enable it then you should add

    Code
    brcmfmac.debug=0x????????

    to /flash/cmdline.txt where ???????? is a hexadecimal number comprising the bit values documented here: linux/debug.h at rpi-4.9.y · raspberrypi/linux · GitHub

    Debug information will appear in the kernel log (dmesg, journalctl etc.)

    Don't be tempted to use brcmfmac.debug=0xffffffff as that is an invalid parameter value and will cause the driver to fail to load.

    You will also have "forensic" data available from:

    Code
    cat /sys/kernel/debug/brcmfmac/mmc1\:0001\:1/forensics

    This github issue may also be worth a read:

    wlan freezes in raspberry pi 3 · Issue #1342 · raspberrypi/linux · GitHub

    Can you try loading the old RPi WiFi firmware to see if that helps:

    Code
    mkdir /storage/.config/firmware
    cd /storage/.config/firmware
    wget -q http://milhouse.libreelec.tv/other/brcmwifiv0.1.tar.gz -O- | tar xvz
    reboot

    Once your device has rebooted you can confirm the old firmware has loaded by checking dmesg which should look as follows:

    Code
    # dmesg | grep brcmfmac
    [    3.835921] usbcore: registered new interface driver brcmfmac
    [    3.963630] brcmfmac: brcmf_c_preinit_dcmds: Firmware version = wl0: Aug 29 2016 20:48:16 version 7.45.41.26 (r640327) FWID 01-4527cfab

    If you are running the new firmware you will see:

    Code
    # dmesg | grep brcmfmac
    [    4.021832] usbcore: registered new interface driver brcmfmac
    [    4.195680] brcmfmac: brcmf_c_preinit_dcmds: Firmware version = wl0: Aug  7 2017 00:46:29 version 7.45.41.46 (r666254 CY) FWID 01-f8a78378

    Right, sorry - I thought 8.1.0 included 384.69 but that's in a later (possibly unpublished) candidate.

    In that case, I'd say this is likely to be a Kodi 17 issue and will need a trac ticket. Worth knowing if it's already fixed in LE9/Kodi 18 - if not, that information should also be included in the ticket so that it can be fixed in both Kodi 17 and 18.

    Kodi doesn't know anything about HDR metadata yet (regardless of hardware) so I wouldn't expect it to work with Kodi on Windows or any other platform until Kodi is updated with HDR support, which might come later in Kodi 18 (still a long way to go) or possibly Kodi 19 (but it definitely won't be in Kodi 17).