Kodi's SSH implementation is beyond awful

  • tl;dr: if you're on an S905 you can't break roughly 9mbit/s of throughput using SSH: here's how to.

    I compiled my own LibreElec build from kszaq's tree using polling on bcmdhd as opposed to soft interrupts thinking the box was maxing out similar to I/O and gained (on average) 4mbps more wireless throughput. This obviously isn't enough as content today (even standard 1080i OTA TV) requires atleast 21mbit/s. Evaluating other options brought me to absurdity: what if I use sshfs on LibreElec, mount my remote shares to a local mountpoint, then point the box to that local mountpoint?

    Compiled sshfs (which is also available via nettools LibreELEC.tv/packages/addons/addon-depends/network-tools-depends at master · LibreELEC/LibreELEC.tv · GitHub ).

    Created some keys, added them to my server.

    In autostart.sh, added the following (which is gross):

    Added my libraries in Kodi to point to /tmp/mnt/FileServer...

    Sure enough, 50mbit/s which is what my laptop gets to the AP.

    This is also way more secure as we're using PKI as opposed to insecure plain-text auth using SSH1 that Kodi still forces... X/

    Hope this helps someone.

    Edited once, last by CvH: fixed code paste (October 3, 2017 at 9:51 PM).

  • Very nice Kyle. i would like to try it out on my KI Pro.

    If i have understood it correctly, does it mean that the Video Buffering issue will be gone with your code implementation or our Network Access Speed will be increased or our storage Disk Access and writing Speed will be Improved ?

    Can you explain to me in simple Terms pls ? i am not an expert.

  • It results in different (more efficient) code paths being used at kernel level and this results in NAS file transfers achieving higher throughput. NFS mounts should give an event faster rate as there's no encrypt/decrypt processing required unlike SSHFS mounts. If you're using SMB3_11 mounts the speed of SMB should be fairly similar to NFS too.

  • Very nice Kyle. i would like to try it out on my KI Pro.

    If i have understood it correctly, does it mean that the Video Buffering issue will be gone with your code implementation or our Network Access Speed will be increased or our storage Disk Access and writing Speed will be Improved ?

    Can you explain to me in simple Terms pls ? i am not an expert.

    Yes, I was unable to watch 4K/1080p (high-bitrate) content over wireless/wired because of this limitation. After switching to this method of mounting shares outside of the application and then pointing the app to these FUSE shares, I can now watch any recorded TV I have. I might try CIFS to my router, but as this is a satellite site the backing software is still sshfs; just depends on where it's located. Using Kodi with this method in-app resulted in actually worse performance than using SSH in Kodi.

    I was/am rolling with the following, but I don't think it's necessary anymore.

    LibreELEC:~ # cat .kodi/userdata/advancedsettings.xml

    <advancedsettings>

      <cache>

        <buffermode>1</buffermode>

        <memorysize>1239460608</memorysize>

        <readfactor>30.0</readfactor>

      </cache>

    </advancedsettings>

    LibreELEC:~ #

    PS: What's up with the weird newlines in [/code] tags?

  • Be aware here when testing by playing something from the movie library. My movie library was built on a sftp:// path. This was changed to a local path where the archive was sshfs mounted without updating the db.

    You could still start and play everything from the indexed library but nothing in advancedsettings.xml was applied. This even with buffermode 1 (all filesystems). However, wipe and update the DB and it will be fine.

    In my case, increasing the ”readfactor” fixed the lag and hickups. Kodi just didn’t utilize the available bandwidth without increasing this a lot. Memory size didn’t matter much as the buffer wasn’t filled fast enough anyways.