Posts by milhouse

    The GUI help text for the Backup option is:

    Quote

    Create a tar archive containing all LibreELEC and Kodi configuration settings, databases and thumbnail content. Backup files will be stored in /storage/backups

    The option is called the System Backup because it will backup all of the systems data.

    Backing up the OS as well as the data is completely unnecessary, not to mention pointless, as how else would you be able to restore the data from a 17.4 backup on a 17.6 system if the restore always took you back to a 17.4 system? If you actually want to go back to 17.4 then downgrade the OS, then restore your 17.4 data.

    There's no need to include LibreELEC itself in the data backup because upgrading/downgrading is so easy - simply drop the .tar or .img.gz file in the Samba Update folder and reboot. You can find all releases in the archive.

    To give a concrete example, having created samba.conf based on samba.conf.sample, add the following to the end:

    For access to /storage:

    Code
    [Storage]
      path = /storage
      available = yes
      browsable = yes
      public = yes
      writable = yes

    For access to the root folder:

    Code
    [Root]
      path = /
      available = yes
      browsable = yes
      public = yes
      writable = yes

    then restart smbd with "systemctl restart smbd", or reboot, and the new share(s) should be visible in your client machine.

    Unless the situation improves with the out-of-tree WiFi drivers and 4.15 we may not have a choice! :)

    The other option is to continue with 4.14.y in LE9 when we had planned on using 4.15.y because the WiFi drivers are still broken, but hopefully they'll be fixed eventually (still early days for 4.15-rc).

    What's the state of iwd and could we use it in LE9 with in-kernel drivers? Or do you see it as an LE10 feature (possibly due to iwd immaturity?)

    Yes I think that's likely. We've looked at switching to iwd and this may make it easier to switch to the in-kernel rtl8xxx driver.

    The changes required in 4.15 are making it more likely (IMHO) that we will drop the out-of-tree WiFi drivers sooner than later, certainly for RPi/RPi2/Generic or any other project that builds with a mainline kernel. I don't have the time to spend on these drivers trying to fix them (particularly as I'd only be making "blind" changes) so if they're not fixed upstream by the community I guess they'll remain broken (I saw you had committed some changes, thanks for that).

    Making the switch to the in-kernel driver and testing/getting feedback may be the only way we can determine whether the mainline driver is "good enough" to make the move permanently. Perhaps it's something we can trial with 4.15-rc considering all the RTL* drivers are broken (not entirely sure how to make the switch, haven't looked).

    script.module.pycryptodome is present in the LE you mention:

    Do you say it's not present because the Kodi add-on system claims it is a missing dependency?

    Unfortunately this is (most probably) a Kodi issue (due to the built-in nature of the addon confusing Kodi), and is just cosmetic - Python works so ignore it.

    Your posts aren't really clear as to what the problem is/was - are you having issues with the LibreELEC Kodi client accessing your Windows shares, or your other Android/Windows devices accessing the LibreELEC Samba server?

    Thanks, got it working but had to force smb1

    Assuming your issue is with the Kodi client accessing your Windows share, then that's really odd because Windows 7 (at least Ultimate, which is what I'm using) supports SMB2 (specifically, SMB 2.10 but not SMB3 which is supported by Win8/Win10).

    You should be able to connect to a Windows 7 share with the default settings In Kodi > Services > SMB Client (Expert/Advanced settings level required):

    * Min Protocol = None (ie. SMB1 for now - this might change to be SMB2, specifically SMB 2.10, as default in future releases)

    * Max Protocol = None (ie. the maximum supported protocol for the client, currently this is SMB3 specifically SMB 3.11)


    With these default settings Kodi will try to establish an SMB1 connection with the server (which may or may not work depending on your server configuration) before proceeding to establish an SMB2 connection (which should succeed with Windows 7).

    Since the Samba client will always attempt an SMB1 connection whenever SMB1 is enabled on the client - even before proceeding with the SMB2 connection - you should always set the Min Protocol to SMB2 (and disable SMB1 on the client) if you want to minimise the risk of any SMB1 exploit. You should of course also disable SMB1 on your server(s) too, however this might be impossible if you have older clients that can only connect using SMB1.

    Anonymous Windows shares are NOT supported by Kodi so you should ensure that access to the Windows 7 share is restricted with a username/password and that "password authentication" is enabled on the Windows share. Kodi should then prompt for a username/password when accessing the share.

    Network browsing is supported by Kodi only if the client is using SMB1, and even then it may not work.

    You haven't said what the exact problem is but it if it's the inability to browse the network then this is a known issue resulting from SMB1 being disabled in most servers these days, and even when SMB1 is enabled the network browsing feature may not work (it depends on numerous flaky parts of Samba working together, which rarely happens) so just add your sources using the "Add network location..." option, and always use "min protocol = SMB2" for the client (and ideally the Windows server).

    The LibreELEC Samba Server on the other hand is configured differently using slightly "harder" security settings by default (go to Settings > LibreELEC Settings > Services for the Samba server settings). The LibreELEC Server supports "server min protocol = SMB2" and "server max protocol = SMB3" ie. it accepts from clients only SMB 2.10 to SMB 3.11 connections.

    Windows 7 should not have a problem connecting to the LibreELEC Samba server when configured with default settings (unless maybe you have a Windows firewall issue). Your Android devices on the other hand may have problems if they only support SMB1, but setting "server min protocol = SMB1" should fix that (however it does leave you with an elevated security risk, which is your choice).

    I don't know if you mean you get the connection timeout in Kodi when accessing the Windows 10 Share (this indicates that the Kodi libsmbclient is not able to negotiate a suitable protocol with the server, likely you are trying to use SMB1 on the client when SMB1 is disabled on the Windows 10 PC). Or if you get the timeout message in Windows 10 when accessing the LibreELEC Samba server from your Windows PC (by default the LE Samba Server allows only SMB2 and SMB3 connections, both of which your Windows 10 PC should support).

    Hopefully you have activated the Samba Server in LibreELEC (just above SSH on/off in the LibreELEC Settings add-on) and you can access the LibreELEC Samba shares. If so, then in File Explorer on your Windows 10 PC type in \\###.###.###.###\Logfiles in the address bar (where ###.###.###.### is the IP address of your LibreELEC client) and open the latest log ZIP file to view the contents (maybe you'll be able to work out the problem), or upload the ZIP file to dropbox/googledrive if you cannot.

    If you can't connect to the client with ssh or Samba, and have disabled the Windows firewall etc., then are you sure you're using the correct IP address? Pinging an IP address and getting a response doesn't really prove that the LibreELEC client has a working connection - you could be pinging the wrong device on your network!

    For those using Libreelec, the file to update is:

    /flash/extlinux.conf

    It will depend how old your installation is - yours sounds like it might have originally been an OpenELEC installation so is using /flash/extlinux.conf.

    Fresh installs of LibreELEC use a more up-to date version of syslinux which now uses /flash/syslinux.cfg (when booting in legacy BIOS mode) or /flash/EFI/BOOT/syslinux (when booting with UEFI).

    craigehicks yes we were aware that fewer nss_mdns shared object libraries were being installed after the nss_mdns bump, but weren't aware it had had an effect on Avahi. I'll run some tests to determine the minimum number of nss_mdns libraries needed to get Avahi to stop whining, and hopefully that will help. Thanks.

    I'm not an expert on .local domains so someone else will have to confirm how they are supposed to be used.

    Yes! If your PSU is marginal then it's entirely possible you may have no issues with LE7 but instability with LE8.

    LE8 has new firmware updates that can cause more power to be consumed in exchange for improved performance (ie. more work is now done by the GPU instead of or in combination with the CPU). If the system is freezing or crashing during a library scan then this would again suggest insufficient power as this process stresses both CPU and GPU components.

    Try a good quality 2.5A+ PSU with a decent USB power cable (ie. not made of thin wire, as this can result in voltage drop). You can't go wrong with the official Raspberry Pi power adapter.