[velqn]

What puzzles me is the following. I am experiencing the very same issues like this user here -> PI 2 extremely poor performance video playback He just restarted his NAS and voila, it was all working. 

Some background:
- I have a Zyxel NAS NSA325v2. Samba version was 3.5.6. I upgraded it to 3.6.25
- I have a Linksys WRT1900ACS. It was running Chaos 15.05 and I upgraded it to LEDE Reboot 17.01.4 r3560-79f57e422d Did not make any difference  

What is mostly strange it that I can play smoothly all videos via uPnP. I tried OpenELEC, LibreELEC, and all Kodi 17 based versions cannot play big video files (30-40gb) via SAMBA. But with latest LibreELEC 9.x it all works fine! All my devices are hard wired, the NAS is 1gb, the routher is 1gb, the Rpi3 is 100mb.

I am really out of any ideas. I tried the custom 8.2.3 build with 64k smb chunk size but still no good luck via Samba. Any ideas guys?

I am not even sure anymore if that`s related to samba chunk size, rather something changed from Kodi 17 to 18... no clue though what.

[zehner]

What do you mean with smoothly? Does KODI buffer or do you have stuttering? What format (codec) have your tested files?

I have the same NAS and a Pi2 and a Pi3 and after a few optimizations I can stream blurays even via WIFI, so your hardware should not be the limiting factor. Recommended optimizations (let's assume you have no errors in your configuration)

- Prefer linux system mounts (fstab) over KODI mounts (smb://). Really a huge difference (nearly double the speed) in my tests a few years ago
- Prefer NFS over UPNP over SMB (but NFS needs a few extra configuration steps with this NAS)
- Check your KODI cache settings http://kodi.wiki/view/HOW-TO%3AModify_the_video_cache . The pi shares USB and LAN lanes, so a good cache setting can compensate a high load on USB or LAN
- Check your /boot/config.txt (neither my pi2, nor my pi3 needs overclocking, but gpu_mem=320 doesn't hurt)
- Switch between OMX and MMAL player in KODI (for me OMX with licenses works best for most blurays)

[velqn]

Hello zehner,

thank you for replying! I am happy that somebody else around has the same setup. In fact I did play with my cache settings and came up with a stable stream, no buffering, no stutter with this settings in advancedsettings.xml:


    <buffermode>1</bufferingmode>
    <memorysize>139460608</memorysize>
    <readfactor>20</readfactor>

Else, some more info:
- I tried NFS and it was the same, but I will definitely try mounting through fstab
- I switched gpu_mem to 320
- with the above config it`s OKAY
- I am using a modest overclock directly from the LS80-script.openelec.rpi.config-0.20.1-0-g34099b0.zip plugin - it just modifies the config.txt for you

This was the codec/movie tested (25gb of size):

Container.......: Matroska
Size............: 24.1 GB
Source(s).......: Blu-ray 1080p AVC DTS-HD MA 5.1
Compression.....: no zlib, no header stripping
---(VIDEO)----
Codec...........: AVC
Type............: progressive
Resolution......: 1920x1080
Bit rate........: 28.6 Mbps
Frame rate......: 23.976 fps
---(AUDIO)----
Format..........: DTS-HD MA
Channels........: 5.1
Bit depth.......: 24 bits
Sample rate.....: 48 kHz
Bit rate........: 3990 kbps

In reality with Kodi 17.x (LibreELEC 8.X) and the default cache settings  (20mb) it is nearly impossible, video starts, runs for 20-30 seconds, buffering starts, cannot handle, sounds disconnects, video turns to slideshow.

I am very interested into checking this part "Prefer linux system mounts (fstab) over KODI mounts (smb://)" since we know that there were bigger changes in the SMB protocol in Kodi 17.6 LE 8.2.3 - so probably this can make a huge difference, appreciate if you can drop your example or I ll check the net.

I have a H96pro plus Android S912 Amlogic box and it`s hardwired to 1GB - everything smooth, do not have to touch cache at all.

Again, many thanks for your input, really appreciate it.

[zehner]

Check your free memory, your setting
<memorysize>139460608</memorysize>
is from the 1GB scenario in the wiki and the pi memory is shared (320MByte for GPU => 704 for CPU). If you have no free memory after watching a movie you could lower this setting

I have nothing special in my mount options, so 

//IP/FOLDER /MOUNT/POINT auto,rw 0 0

should work (check the net, I write this from memory, at the moment I have no access to my computers). But I can remember, that I've tested a few extra configuration options and no option has made a big difference in throughput

I think the 100MBit net is the limiting factor (that's why your S912 with GBit works, I own a S905x with 100MBit that also needs the cache settings). Your file has an average bitrate of over 30MBit and can have peak bitrates above this value. Every now and then you come close to the limit of your connection. A more efficient protocol or better cache settings can reduce the risk of dropouts

I don't think the SMB updates in LE are the source of your problem, because I have seen the same performance difference in Ubuntu, Suse, Gentoo, ... A system mount (fstab) is always faster as a program mount (e.g. Dolphin in KDE)

[velqn]

Thanks mate!

I tried various options and the only successful mount command was:

mount -t cifs -o sec=none,vers=1.0 //192.168.1.2/video /storage/nas

No other chance to connect to my Zyxel NSA325v2 Will check later if this makes any difference, i.e. not to use the sbm:// from Kodi itsels.

p.s. this cachememsize pumps up to 50% of the already available RAM for Kodi, so when I check, it uses max 80-90MB of buffer, so less would also work well I guess.

[velqn]

Jesus Christ, this is INSANE crazy!

Installed LibreELEC 8.2.3 from scratch - gpu_mem=256 untouched, no advancedsettings.xml (i.e. cache untouched), no hardware codecs entered...

Just mounted my NAS to /storage/nas ... and it all FLIES now.

Thank you mate!!! God bless you!

[velqn]

I have created autostart.sh :

!/bin/sh
(sleep 5;
mount -t cifs -o sec=none,vers=1.0 //192.168.1.2/video /storage/nas
)&

Decided this would be easier then modifying fstab, I guess should bring same result. NET result - everything working FLAWless now.

For future searches, if somebody experience same issues, hope this will help.