I came across a few threads elsewhere in which setting the CIFS caching to cache=loose helped. (Your log showed that you have cache=strict, which is the default.)
Just tried, no difference 
Had no effect sadly.
Can you test over a longer timeframe (2 minutes) and post the results here (also ensure that you are testing both send and receive).
How have you mounted the SMB share? How do you test throughput?
Tried these now, and I can see the exported list with showmount -e, and on windows I can map the drive and see the subfolders.
However, as soon as I try to list the contents in one of the folders, HaneWin simply crashes the NFSD service with some dll error, so I can’t use it sadly =(
It was suggested in another thread to:
“Install CRDA: sudo apt-get install crda then edit /etc/default/crda and set the country code to SE. This has sometimes helped.”
I set it to the same as I’ve set my router to and that made a significant difference. (I use a cable, wireless works on most files but not all for me)
Perhaps that’s something to try…
You could try contacting the Hanewin author by email - I’ve found him quite helpful in the past. Double-check that all three of the Hanewin executables have firewall exceptions too.
I’ve done so multiple times before.
With Iperf3 read is around 140Mbps, even if running for 15+ minutes, send is around the same.
Both through AutoFS as well as manually mounting. Tests were done by running “cp” of a file with known size and calculating full time, I also monitored my router traffic and there was no weirdness going on (i.e. it was fairly stable close to the calculated speed, no write 100MB in a second then be idle for 10 seconds or such).
Running wget to a public web server I’m seeing 140+ Mbps as well, so it seems isolated either to my local network, or to SMB/FTP (I was mistaken, never got NFS working, trying to set it up now byt Hanewin keeps crashing).
Also trying to spin up a simple webserver to try wget locally.
Yup, already set country without success =(
Turns out HaneWin requires MAX_PATH to be enabled on Windows.
Using NFS I’m seeing 140Mbps transfers. No idea why SMB would be that much slower over WiFi (it’s maxing out over ethernet), especially not since FTP also showed the same issue.
@sam_nazarko
Could there be an issue with the SMB client/config that’s shipped with OSMC? Sadly I don’t have another Linux machine with WiFi to test from, but given that there is no performance drop whatsoever over ethernet I’m a bit confused as to the behavior. SMB over WiFi maxes out when I use a Windows machine as the client at least, so the protocol itself should work just fine.
Except, as you already noted:
The two protocols are very different, which ,at least to me, suggests that the problem might lie elsewhere. A quick scan through the forum should also show that this problem isn’t widespread, so there appears to be something relatively unique about your set-up that has so far eluded our efforts to resolve your problem.
Nevertheless, I’m happy to see you’ve finally found a workable solution.
Yeah, no idea what’s really going on, since I completely maxed out the Gbit ethernet, and WiFi was so far below the max speeds it’s silly (running at like 25% of max).
Oh well, finally managed to get the NFS share running on Windows Server, no issues whatsoever maxing out.
Just a few hours to spend redoing all the utility things around the NAS, but at least it all works now.
Thanks so much to everyone in this thread for the help!
2 Likes
I should add that I had the same issue on Windows 10 with Lav filters that would stutter on 5% of the 4k remuxes that were 70mbit on wifi. I had fixed it previously by replacing my 10m HDMI cable with a new 2.0 cable. But when trying to stream over my pci-e 1900ac wifi card to my enterprise wan 1900 WAP. I still experienced the same stuttering on those 5%. Which I pegged down to a lack of bandwidth on both issues.
My conclusion was that the theoretical speed you get from wifi and hdmi is not the reality and need more over head for reality situations.
1 Like